Transfers and Authorization

A MIP20 transfer debits one account and credits another. The balance owner may initiate it directly, give an operator an allowance, or sign a single-use ERC-3009 transfer authorization. Every path reaches the same MIP20 state transition.

​

Transfer lifecycle

Direct transfers, delegated transfers, ERC-3009 transfers, and higher-level contracts that call those methods share the same internal transfer path:

1. Validate the transfer’s authorization.
2. Call the receive policy contract, ReceivePolicy, to check the recipient’s rules.
3. Debit the sender and credit the recipient or quarantine.
4. Emit Transfer with the actual credited destination.

MIP20 checks the sender, recipient, and available balance before applying the debit and credit. The receive policy contract can refuse an ordinary transfer under the recipient’s rules by reverting it or placing the funds in quarantine. Quarantined funds are credited to ReceivePolicy escrow, leaving the intended recipient’s balance unchanged. See Send and Receive Policies for these rules. Transfer events become part of the receipt only if execution succeeds. A revert rolls back the transfer call’s balance changes, policy state, allowance or authorization consumption, and events. An uncaught revert fails the transaction, which still pays gas. A transaction may execute several MIP20 transfers. If its outer call reverts, all of its application state changes roll back. A contract can catch a failed transfer and continue, so a successful transaction receipt alone does not prove that every attempted transfer succeeded.

​

Authorization, operation, and submission

MIP20 distinguishes the sender from the operator that calls the token contract to perform the transfer. The sender is the account whose MIP20 balance is debited. An operator can be the approved spender, relayer, or application contract. The account that signs the transaction pays gas. Depending on the transfer path, one account may fill several roles or different accounts may fill them. The receive policy contract treats the account whose balance is debited as the sender, including when a spender or relayer calls the token.

​

Allowances

An allowance authorizes a spender to transfer MIP20 from the approving holder’s balance. The spender chooses when to call transferFrom, the recipient, and the amount, subject to the remaining allowance and available balance. Calling approve(spender, amount) replaces the current allowance, including a nonzero value. A completed transfer consumes its finite allowance even when the receive policy contract quarantines the funds under the recipient’s rules. A revert restores the allowance. Exact allowance behavior belongs in the MIP20 reference.

​

ERC-3009 transfer authorization

ERC-3009 separates authorization of one transfer from submission of the transaction that executes it. The sender signs EIP-712 data binding the MIP20 token, sender, recipient, exact amount, validity window, and a random authorization nonce. MIP20 verifies an ECDSA signature recovering the sender address. Accounts with code can also authorize through ERC-1271 using the bytes-signature form. Any account can submit transferWithAuthorization, but the signature prevents it from changing the recipient or amount. Only the named recipient can submit receiveWithAuthorization. MIP20 records the (sender, authorization nonce) pair before executing the transfer, preventing successful replay. Quarantine consumes that nonce. A transfer or application revert rolls back both the transfer and nonce consumption, so the authorization remains unused. Additional application policy evidence needs its own authentication because it is outside the ERC-3009 signed fields. Signing and Typed Data defines the domains, signed fields, and supported signature forms.

​

When a transfer is complete

A successful receipt containing the expected token’s Transfer event proves that the movement executed in its containing block. Check its destination to distinguish delivery to the intended recipient from quarantine. The resulting balance is reliable as canonical state after the block is finalized. See Consensus and finality for that boundary.