Conversation
Adds an asset specification to the existing tvm namespace, covering 215 assets that a cross-reference project needs to name. The CAIP-2 profile is unchanged.
This branch has not been deployed
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
1 participant
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.
Adds a CAIP-19 asset profile to the existing
tvmnamespace. The CAIP-2 profile is already ratified and is not touched.Who wrote this
I do not represent the tvm ecosystem. I maintain FAR, an open cross-reference between CAIP-19, CoinGecko and ISO 24165 (DTI) identifiers, which needs a way to name 215 assets on this chain. CASA's README invites profiles added to an existing namespace, so this documents how assets are addressed rather than claiming to speak for anyone. Offered for the tvm community to correct, adopt or replace.
Asset namespaces
slip44, tep74, tep62, extracur, tip3, tip4What this profile establishes
Canonical form is the raw address (
0%3A<64 hex>), not the user-friendly base64 form — because the user-friendly form is not unique. Its tag byte encodes bounceability and a testnet flag that are not part of the account, so one account has 4 tag variants × 2 base64 alphabets = 8 valid strings. I implemented TEP-2 encode/decode and confirmed byte-identical results against toncenter'sdetectAddress.A silent-failure case worth reading. The standard-base64 spelling of a jetton master produces a structurally valid but wrong CAIP-19:
tvm:-239/tep74:EQCxE6…Nw2Id/sDssatisfies every production in the grammar — the reference is a truncated address andsDsparses as atoken_id. It does not fail validation; it names something else.Indexers disagree on the TEP-62 index. For one live collection the contract returns a 72-digit index while tonapi reports a negative int64 — confirmed arithmetically as the low 64 bits read as signed.
Every example was verified against a live node or explorer; anything that could not be verified is marked as such in the document rather than asserted.
discussions-topoints at 0xcounting/FAR#1.