Skip to content

refactor(intents): extract the decoder into a crate with no chain dependency - #490

Draft
shahan-khatchadourian-anchorage wants to merge 3 commits into
shahankhatchadourian/solana-offchain-message-renderfrom
shahankhatch/vp3-intents-crate
Draft

shahan-khatchadourian-anchorage wants to merge 3 commits into
shahankhatchadourian/solana-offchain-message-renderfrom
shahankhatch/vp3-intents-crate

Conversation

@shahan-khatchadourian-anchorage

@shahan-khatchadourian-anchorage shahan-khatchadourian-anchorage commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

VP3. Moves the NEAR Intents decoder into visualsign-intents, a crate with no chain dependency, so Solana and Ethereum decode intents without depending on NEAR. Stacked on #489.

INTENTS_RECEIVER moves with it — a multi-token asset id names that contract, which is a property of intents, not of a chain. presets/intents.rs becomes a re-export so the NEAR gate reads unchanged.

Not here: the NEP-413 envelope renderer, which needs Nep413Payload from #492; and defuse-nep413, which no source in the crate uses.

59 tests green across the affected crates.

…endency

The NEAR Intents decoder lived under visualsign-near/src/presets/intents, but
the same DefusePayload reaches Solana and Ethereum through their own message
envelopes. Moving it to visualsign-intents, a crate with no chain dependency,
lets each chain parser decode intents without depending on NEAR.

What stays NEAR-specific is recognizing that a payload carries intents at all,
which is the receiver_id/method_name gate in convert; presets/intents.rs is now
a re-export so that gate reads unchanged.

INTENTS_RECEIVER moves with the decoder. A multi-token asset id names that
contract when the balance it wraps is one the protocol holds, so resolving such
an id is a property of intents rather than of any chain; the NEAR crate now
takes the constant from here instead of defining it.

The NEP-413 envelope renderer is not here: it needs Nep413Payload, which the
NEAR envelope work introduces, so it lands with that.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CodeQL's cleartext-logging query flags a `panic!`/`assert!` message that
carries a ValidationError string embedding the receiver account id. The
account id is not secret -- it's the same value VisualSign renders to a
signer -- but the query can't tell that, so the fix is to stop embedding
the tainted string rather than argue with the query per PR.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Every other workspace member opts into [workspace.lints] via [lints]
workspace = true (unwrap_used/expect_used/panic deny, unsafe_code
forbid). visualsign-intents was missing this section, so its
production code carried none of those guarantees even though its test
modules already use the standard #[allow(...)] shape that assumes the
crate-level deny is active.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

This branch has not been deployed

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant