docs(tips): TIP-1028, Address-Level Receive Policies#3791
Open
docs(tips): TIP-1028, Address-Level Receive Policies#3791
Conversation
Amp-Thread-ID: https://ampcode.com/threads/T-019cfd21-479f-705d-8141-d61952cbed4d Co-authored-by: Amp <amp@ampcode.com>
Updates TIP-1028 to use escrowed handling for blocked TIP-20 inbounds, clarify claim and recovery semantics, and document Tempo-specific integration behavior. Co-Authored-By: malleshpai <5857042+malleshpai@users.noreply.github.com>
Co-Authored-By: malleshpai <5857042+malleshpai@users.noreply.github.com>
Co-Authored-By: malleshpai <5857042+malleshpai@users.noreply.github.com>
Co-authored-by: malleshpai <5857042+malleshpai@users.noreply.github.com> Amp-Thread-ID: https://ampcode.com/threads/T-019dab7c-efa4-7608-9058-7380358fbdb7 Co-authored-by: Amp <amp@ampcode.com>
Co-Authored-By: malleshpai <5857042+malleshpai@users.noreply.github.com>
Co-Authored-By: malleshpai <5857042+malleshpai@users.noreply.github.com>
Co-Authored-By: malleshpai <5857042+malleshpai@users.noreply.github.com>
Co-Authored-By: malleshpai <5857042+malleshpai@users.noreply.github.com>
Co-Authored-By: malleshpai <5857042+malleshpai@users.noreply.github.com>
Co-Authored-By: malleshpai <5857042+malleshpai@users.noreply.github.com>
Co-authored-by: malleshpai <5857042+malleshpai@users.noreply.github.com> Amp-Thread-ID: https://ampcode.com/threads/T-019dab7c-efa4-7608-9058-7380358fbdb7 Co-authored-by: Amp <amp@ampcode.com>
Co-authored-by: Amp <amp@ampcode.com> Amp-Thread-ID: https://ampcode.com/threads/T-019ddf7e-fb21-76a8-b851-e98e593519cd
0xrusowsky
reviewed
May 1, 2026
Contributor
0xrusowsky
left a comment
0xrusowsky
left a comment
There was a problem hiding this comment.
i think this progressive narrative describing components incrementally works way better, nice
|
|
||
| The blocked balance for each TIP-20 token sits in that token's `balances[ESCROW_ADDRESS]` slot. | ||
|
|
||
| ### Restrictions on `ESCROW_ADDRESS` |
Contributor
There was a problem hiding this comment.
should also mention that escrow address doesn't accrue tip20 rewards
Contributor
Author
There was a problem hiding this comment.
Do we want to explicitly reject this? Would allowing it break any assumptions?
It feels more like a user error that can be reversed, but otherwise expected behavior? This would be the same as a user setting their rewards address as an address they do not have access to. Lmk if I am overlooking something here though.
Contributor
There was a problem hiding this comment.
no strong opinion. if it's easy enough i would say escrow can't receive rewards, just so that we're minimizing chances of unclaimable rewards floating around?
Co-authored-by: malleshpai <mallesh.pai@gmail.com>
samczsun
reviewed
May 1, 2026
| - `kind`: `TRANSFER` or `MINT`. | ||
| - `memo`: original memo for memo-bearing paths, `bytes32(0)` otherwise. | ||
| - `blockedAt`: block timestamp captured at receipt creation. | ||
| - `blockedNonce`: monotonically increasing global disambiguator assigned at receipt creation. |
Contributor
There was a problem hiding this comment.
suppose the same block has multiple blocked transfers with the same other entries (e.g. same sender, no memo, transfer, etc etc). the nonce ensures uniqueness
Co-authored-by: samczsun <samczsun@users.noreply.github.com>
0xrusowsky
reviewed
May 4, 2026
0xalpharush
reviewed
May 5, 2026
0xalpharush
reviewed
May 5, 2026
0xrusowsky
reviewed
May 5, 2026
0xrusowsky
reviewed
May 5, 2026
Co-authored-by: 0xrusowsky <90208954+0xrusowsky@users.noreply.github.com>
malleshpai
approved these changes
May 5, 2026
review feedback --------- Co-authored-by: 0xKitsune <0xKitsune@protonmail.com> Co-authored-by: 0xKitsune <77890308+0xKitsune@users.noreply.github.com>
0xrusowsky
approved these changes
May 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #3173, rewrites the spec for readability without changing the protocol design.
This PR introduces TIP-1028, which extends TIP-403 with address-level receive policies that let a receiver control which TIP-20 tokens they accept and who can send them. When a transfer or mint is blocked by a receive policy, the funds are sent to escrow instead and can later be claimed by the receiver or a designated recovery contract.