--- id: TIP-1095 title: Policy-Aware Channel Reserve Transfers description: Applies TIP-403 policy to the logical payer-payee path of TIP-1034 channels while preserving unilateral refunds. authors: Georgios Konstantopoulos status: Draft related: TIP-20, TIP-403, TIP-1015, TIP-1028, TIP-1034, TIP-1035 protocolVersion: T12 --- # TIP-1095: Policy-Aware Channel Reserve Transfers ## Abstract This TIP lets recipient-restricted TIP-20 tokens use TIP-1034 channels without authorizing the channel reserve or every payer as a recipient. Funding and capture apply TIP-403 to the logical `payer -> payee` payment. Refunds return funds to the payer without TIP-403 authorization. Token pause state and TIP-1028 receive policies still apply to every movement. ## Motivation A channel moves tokens through reserve custody: ```text funding: payer -> reserve capture: reserve -> payee refund: reserve -> payer ``` A recipient policy that allows only the payee rejects funding because the reserve is not allowed, and rejects refunds because the payer is not allowed. Allowing the reserve and every payer would weaken the policy by making those addresses valid recipients for ordinary transfers. The channel already authenticates its payer, payee, and balances. TIP-403 can therefore apply to the payment the channel represents instead of its intermediate custody movements. A blanket exemption for reserve transfers would be unsafe because it could send captured funds to a forbidden payee. ## Assumptions - The TIP-1034 reserve is trusted protocol code. Its descriptor binds an immutable payer and payee to each channel. - The reserve can use an internal TIP-20 transfer function that is unavailable through the public TIP-20 ABI. - TIP-1028 receive policies and token pause state remain independent of TIP-403 authorization. ## Threat Model - Channel participants may choose channel fields and submit valid vouchers, but cannot redirect a capture or refund away from the descriptor-bound address. - The token issuer may change TIP-403 policy or pause the token. This may delay a channel operation, but cannot redirect reserve custody. - A TIP-1028 policy may reject a capture or refund. The operation must remain retryable. --- # Specification After T12, TIP-403 authorization for channel operations is: | Operation | Physical movement | TIP-403 authorization | |---|---|---| | `open`, nonzero `topUp` | `payer -> reserve` | `payer -> payee` | | `settle`, capture in `close` | `reserve -> payee` | `payer -> payee` | | refund in `close`, `withdraw` | `reserve -> payer` | bypassed | For a virtual payee, authorization uses its resolved master address, as in an ordinary TIP-20 transfer. ## Funding and Capture Before funding or capture, the reserve must check the descriptor payer as the TIP-403 sender and the resolved descriptor payee as the TIP-403 recipient under the token's current policy. It then moves the physical balance without separately applying TIP-403 to the reserve address. Before `open` or a nonzero `topUp` moves funds, the reserve must also check that the payee's current TIP-1028 policy accepts the channel token from the sender that will be presented during capture: the payer for channels opened at or after T12, and the reserve for older channels. This check does not lock the policy. If the payee later changes it, capture may fail until the payment is accepted again. All existing channel checks still apply. Token pause state, balances, access-key limits, recipient validity, and TIP-1028 policy must be enforced as they are for native TIP-20 transfers. A failed capture must not advance cumulative settlement or close the channel. ## Refunds The refund in `close` and the payer-only `withdraw` path bypass TIP-403 only when: - the physical sender is the channel reserve; - the recipient is the descriptor payer; and - the amount is the refund derived from authenticated channel state. Pause state, recipient validity, and TIP-1028 policy still apply. If a refund is rejected, the operation must revert without deleting the channel or moving funds, so the payer can update its receive policy and retry. `requestClose` followed by `withdraw` remains unilateral. The payer does not need the issuer, payee, or operator to authorize the refund under TIP-403. ## TIP-20 Integration The transfer function used by the reserve must be internal-only and must reject transfers where neither endpoint is the channel reserve. Funding preflights the payee's policy, capture uses the descriptor payer as the TIP-1028 sender, and refunds use the reserve. TIP-1028 rejection must revert instead of creating a `ReceivePolicyGuard` receipt, because channel accounting cannot represent guarded funds. Successful movements update balances and emit the same physical `Transfer` events as ordinary TIP-20 movements. ## Activation and Compatibility This behavior activates at T12 for channels opened at or after T12. Before T12, TIP-1034 keeps its original physical transfer-policy checks. Channels opened before T12 continue presenting the channel reserve as the TIP-1028 sender during capture, including after T12 activation. No on-chain channel migration or receive-policy update is required for existing channels. A channel records which receive-policy sender rule was active when it opened without changing its public ABI, channel ID, voucher, event, or storage-slot count. This TIP does not change TIP-403 behavior outside the channel reserve. # Tooling N/A. Existing TIP-1034 clients and session formats are unchanged. # Observability No new events are added. Existing TIP-20 `Transfer` events and TIP-1034 channel events remain sufficient for monitoring and debugging, but they represent different sides of a channel movement: | Existing events | What it records | Interpretation | |---|---|---| | TIP-20 `Transfer` event | Physical token movement and custody | For settlement and capture, the physical path is `channel reserve -> payee`. It does not identify the payer used for policy authorization | | TIP-1034 channel events | Logical channel parties and accounting | Use the payer, payee, and operation-specific amount fields to correlate the movement with the logical payment | For channels opened before T12, settlement and capture continue presenting the channel reserve as the sender to the payee's receive policy. For channels opened at or after T12, authorization uses the `payer -> payee` path while the physical movement and `Transfer` event remain `channel reserve -> payee`. A `Transfer` from the channel reserve to the payee therefore does not by itself identify which sender was evaluated by the receive policy. # Invariants - Ordinary TIP-20 transfers remain subject to the token's TIP-403 policy. - Funding and capture succeed only while the logical `payer -> payee` transfer is authorized. - Existing channels retain the TIP-1028 sender rule under which they were funded. - Funding requires the payee's current TIP-1028 policy to accept the token from the channel's receive-policy sender. - Captured funds can go only to the descriptor payee. - A refund can go only to the descriptor payer and cannot exceed the refundable channel balance. - The payer can recover refundable funds without being an authorized TIP-403 recipient. - The TIP-403 bypass is unavailable through the public TIP-20 ABI and is used only for reserve refunds whose recipient and amount come from channel state. - Pause state and TIP-1028 apply to every physical movement. Rejection leaves balances and channel accounting unchanged and creates no guarded receipt. - Token and channel balance conservation is unchanged. - Pre-T12 execution is unchanged. ## References - [TIP-1015: Compound Transfer Policies](tip-1015.md) - [TIP-1028: Address-Level Receive Policies](tip-1028.md) - [TIP-1034: TIP-20 Channel Reserve Precompile](tip-1034.md) - [TIP-1035: Implicit Approval List](tip-1035.md)