Skip to content

Conversation

@friedger
Copy link

This PR

  • adds a definition for CAIP 19 for the Stacks blockchain

@friedger friedger marked this pull request as ready for review May 26, 2023 18:29
@bumblefudge
Copy link
Collaborator

Hey @friedger , glad to see you back! Sorry for slow turnaround time, I'm on family leave, but will still try to get this merged in a reasonable time frame.

@bumblefudge
Copy link
Collaborator

@friedger i'm back! Did you have a chance to review my suggestions?


```
# Stacks Mainnet NFT:
stacks:1/sip9:SP3D6PV2ACBPEKYJTCMH7HEN02KP87QSP8KTEH335.megapont-space-agency/4
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry but I don't see any explanation of the .megapont-space-agency segment in ## Syntax section, nor would it be allowed by Stacks/caip10 or by caip19 itself... is it really necessary or should that information/disambiguation mechanism live elsewhere, for example, in a query or matrix parameter at the end of the URI?

## Syntax

After the [CAIP-2][] (namespace+chainID), a slash defines an `asset_namespace` and an `asset_reference`.
The `asset_namespace` is defined via the SIP or
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sentence fragment? perhaps a commit get left off the PR?

stacks:1/sip9:SP3D6PV2ACBPEKYJTCMH7HEN02KP87QSP8KTEH335.megapont-space-agency/4

# Stacks Mainnet xBTC
stacks:1/sip10:SP3DX3H4FEYZJZ586MFBS25ZW3HZDMEW92260R2PR.Wrapped-Bitcoin
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The stacks/caip10 syntax is case-insensitive (or all-caps, to be more precise) which I assume is carried over from the Stacks native addressing system. Would it make sense or simplify things for this naming convention to match, to reduce the phishing/impersonation vector of i/I/l/L ambiguities, etc etc?

@bumblefudge
Copy link
Collaborator

this is incredibly embarassing to admit (immutably and publicly, no less) but my three in-line comments above were sitting in draft unsent for... a year, thanks to a github.com UX change that passed me by unnoticed. sincere apologies if you got notifications that made no sense referring to unseen comments.

@kyranjamie
Copy link

This is great, would love to see it get merged

@bumblefudge
Copy link
Collaborator

bumblefudge commented Nov 21, 2024

This is great, would love to see it get merged

me too, honestly! @kyranjamie , if you or anyone from the groupchat can answer my clarifying questions above and, if needed, address them in a new PR forked from this one and targeting main, I'm happy to merge! Just need the nits addressed, hehe

whoabuddy added a commit to aibtcdev/namespaces that referenced this pull request Jan 15, 2026
Adds comprehensive CAIP-19 specification for Stacks token assets,
supporting SIP-010 fungible tokens and SIP-009 non-fungible tokens.

Asset reference format: {address}.{contract}.{token-name}

This addresses the feedback from PR ChainAgnostic#68 including:
- Clear documentation of all syntax components
- Case sensitivity handling (addresses vs contract/token names)
- Complete RegEx validation patterns
- Semantics section for each token type

Examples verified against on-chain data (sBTC, Megapont Ape Club).

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@whoabuddy
Copy link

Hi @friedger and @bumblefudge,

We've created an updated implementation that addresses all the review feedback from this PR:

#167 - feat(stacks): add CAIP-19 asset specification

Key changes:

  • Clear documentation of all syntax components ({address}.{contract}.{token-name})
  • Case sensitivity section addressing the security concerns raised
  • Uses . as separator (CAIP-19 compliant, since : not permitted in asset_reference)
  • Complete RegEx, Semantics, and Examples sections
  • Examples verified against current on-chain data (sBTC, Megapont)

Would love your feedback on the updated approach!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants