> ## Documentation Index > Fetch the complete documentation index at: https://docs.metalntwx.com/llms.txt > Use this file to discover all available pages before exploring further. # Transfers and Authorization > How MIP20 transfers are authorized and applied to sender and recipient balances 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](https://docs.metalntwx.com/learn/mip20/handlers-and-policy.md) 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. | Transfer path | Authority over the debit | Token operator | | - | - | - | | Direct transfer | The sender calls from its own account | Sender | | Delegated transfer | The sender grants an allowance | Approved spender | | Relayable ERC-3009 transfer | The sender signs a transfer authorization | Any account that submits it | | Payee-bound ERC-3009 transfer | The sender signs a payee-bound authorization | Recipient | | Application-coordinated transfer | Depends on the application's authority model | Application contract | 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](https://docs.metalntwx.com/reference/assets-and-payments/mip20.md#transfers-and-allowances). ## 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. > [!NOTE] > > A transfer authorization is single-use. It does not reserve funds, create a > recurring mandate, or support later capture. 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](https://docs.metalntwx.com/reference/network-fundamentals/signing.md#mip20-erc-3009) 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](https://docs.metalntwx.com/learn/architecture.md) for that boundary. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.