# Who may move an asset, and what the account holding it is
An announcement can say that a sum of money "can only be moved by a governance vote". That sentence
is about authorisation. Whether the account holding the money enforces anything is a separate
question, and it has a short answer that can be read directly: does the account have code.
This note describes the read, publishes a worked example, and states the limit.
## Why it is a separate read
A governance right is a constraint when something refuses a transfer without the vote. An address that
holds no code cannot refuse anything: whoever holds a key to it, or whoever can make the chain accept a
transaction attributed to it, moves the funds. The published sentence may still be true — the operators
may genuinely require a vote — but it is then a commitment, not a mechanism. Readers who take the
sentence as a mechanism are reading a stronger claim than the text supports.
So the record publishes three things beside each other:
1. the statement as **published** (quoted, with its document and date);
2. the account as **read**, at a pinned block: code length, nonce, balances;
3. the **execution path** that actually moved the asset, from the transaction and its logs.
## How the read works
Six calls, all public.
- `eth_getCode` at the holding address. Zero bytes means an externally owned account: there is no
contract that could hold a rule.
- `eth_getTransactionCount`. A nonce of zero on a funded address means nothing has ever been sent
from it. A non-zero nonce means the address has a history of being the sender of a transaction.
- `eth_getBalance` and `balanceOf` on the token contract, at the read block **and** at a block before
the action. The earlier read is what separates money that arrived in this action from money that was
already sitting there.
- `eth_getTransactionReceipt` on the action transaction, for status, block, gas and the full log list.
- The proxy's EIP-1967 implementation slot (`0x3608…2bbc`) at the block before the action and now. Where
an upgrade is described as temporary, this is what "returned to its original state" looks like.
- The order of the logs inside the receipt. An upgrade that is installed, used, and removed inside one
transaction leaves a readable sequence, and the sequence shows how many times the privileged
capability was installed.
## Worked example — Arbitrum, read 2026-11-01
On 2026-10-30 the Arbitrum Security Council executed an emergency action and froze 8,425 ETH and
74,559,805.2 ARB belonging to a Binance exploit address. The announcement states:
> The funds are now held at `0x0000000000000000000000000000000000000DA0`. The funds can only be moved
> by an ArbitrumDAO Governance vote, which will be coordinated with relevant parties.
**The holding account.** `0x…0DA0` has **zero bytes of code**. Its nonce is **1**, and was already 1
before the action: one transaction has ever been sent from this address, and it was not this one.
**The balances, and the arithmetic of the published figure.** At block 520,152,808 the account holds
**8,426.047679407546 ETH** and **74,559,805.2 ARB**. The ARB figure is exact. The ETH figure is
1.0476794075457292 above the published 8,425, and that difference decomposes completely:
- 0.04999945314671 ETH was already at the address on 2026-10-27, before this action — the residue the
June release left behind to pay its own gas;
- 8,425.997679954398 ETH arrived in this action;
- the published 8,425 is therefore 0.9976799544001551 ETH below the amount transferred. The
announcement states no precision, and this note does not adopt a reason for the difference.
**The execution path.** One Ethereum transaction, block 26,301,886, status 1, 286,045 gas, 11 logs.
The receipt records a sequence: upgrade the Inbox proxy to a temporary implementation, deliver one
cross-chain message (sequence 0x27c65d), upgrade back to the live implementation; then upgrade to the
temporary implementation again, deliver a second message (sequence 0x27c65e), upgrade back again. Two
messages, four `Upgraded` events, one transaction. The Inbox's code and implementation slot are
byte-identical at the block before the transaction and at the read block. The temporary implementation
(`0x980D1F93…A859`) remains deployed and is 359 bytes larger than the live one (`0x7c058AD1…0a10`).
**What the precedent shows.** The same address was used for the 2026-04-21 freeze of 30,765.667401709
ETH. That money left on 2026-06-15, after a constitutional vote: transaction
`0x09795deb…dafdf72`, block 473,716,531, status 1, 30,765.61740170901 ETH to an Aave LLC address,
27,329 gas — and the transaction's **sender field is `0x…0DA0` itself**, nonce 0, type 101. The vote
decided whether to release. The transfer was executed through the same impersonation facility the
freeze had used, reinstalled through the Inbox.
## Reading the sentence
Two readings fit the text. The record publishes both.
**A policy commitment.** A vote is required by the operators who hold the capability. The precedent
supports this reading operationally: the April release followed a Snapshot check that closed
2026-05-07 (For 182,176,773.22 / Against 1,737.79 / Abstain 18,102,391.90 ARB, 1,693 votes) and an
on-chain vote the AIP thread reports as passed, with the payload executed on 2026-06-15.
**A contract-enforced constraint.** Nothing in the state supports this reading. The holding account has
no code, there is no escrow contract at the address, and the release transaction of 2026-06-15 carries
the keyless address as its sender.
What would distinguish them: an action that moves assets out of `0x…0DA0` without a governance vote
falsifies the first; a contract at the holding address, or a release path that requires a governor
execution to succeed, supports the second. Neither exists at this read.
**Record:** [`arbitrum-frozen-funds-authority.json`](../data/authority/arbitrum-frozen-funds-authority.json).
## Limits
- A difference between a published figure and a read figure is arithmetic. It is not a finding about
intent, and this note does not say which figure the announcer meant to publish.
- The function name in the announcement is quoted, not verified in bytecode. The bytecode check
performed here is narrower: the temporary implementation differs in size from the live one, the live
one is byte-identical to its pre-action state, and the live one is what the proxy points at.
- Who submitted or signed the 2026-06-15 release transaction is not established by any source read
here. The transaction's sender field is the keyless address; the submitting party is unknown.
- The ultimate disposition of frozen funds is not known at this read, and nothing here says who
receives them.
- One worked example supports one record. It is not a statement about emergency powers in general, and
the next case may look nothing like this one.
---