Signing Guide

For a Solana send, decode authorization.solana.message_base64 with @solana/web3.js and require all of:

• The fee payer equals authorization.solana.fee_payer, which is ours, because your customer holds no SOL.
• The token mint is the asset you requested, at authorization.solana.decimals.
• Exactly one TransferChecked, from the wallet's associated token account to the recipient's, for exactly the amount you requested, optionally preceded by one idempotent create-account instruction for the recipient. We open first-time accounts and the rent is ours.
• Nothing else. Any additional instruction fails verification.
• The message bytes equal commitment.destination_payload exactly.

Do not check the important fields. Require the whole decoded message to be one of the two legitimate shapes. An instruction you did not think to look for must fail by construction, not by enumeration.

Using near-kit's serializeDelegateActionV2, reconstruct the delegate from values you already hold:

• Your identity: verify authorization.identity.signing_identity equals the identity you registered, which is the hex of your Recovery Key's public bytes.
• Your Primary Signing Key: the one you registered, never a key named in the response.
• The wallet's signing_reference: published at wallet creation and immutable. Compare it to what you stored then.
• The verified payload from step 1.
• The contract constants from the table above.

The number and order of sign calls is part of what you are authorizing. A Solana send is exactly one. Rebuilding the wrong count or order yields a different digest, which is precisely how a smuggled extra signature request fails without you enumerating it.

Compute the canonical NEP-461 v2 hash of your rebuild and require it to equal signing.digest:

digest = SHA-256( u32_le(1073742435) || 0x00 || borsh(delegate) )

1073742435 is the NEP-611 domain discriminant (2^30 plus 611), and 0x00 is the payload version byte. near-kit computes this for you.

As a final check, require anti_replay.expiry_unix to be within 900 seconds of your own clock. That needs no chain access, which is why the limit is part of the contract.

Sign the 32-byte digest raw with your Primary Signing Key. No prefix, no extra hashing, pure ed25519. Return it base64-encoded.

curl -s $BASE/api/wallets/wal_.../operations/wop_.../authorize \
  -H "Api-Key: $KEY" -H "Content-Type: application/json" \
  -d '{"signature": "<base64 raw 64-byte ed25519>"}'

We verify it against your registered key at the door (422 invalid_signature otherwise), and the wire format re-verifies it again before relay.

POST /dashboard/partner/wallet_keys with both public halves returns the registration and an activation object carrying the same signing envelope a send does. If it comes back null, the relay could not prepare it just then: retry with POST /dashboard/partner/wallet_keys/activation.

{
  "object": "wallet_key_activation",
  "signing_identity": "9f1c...",
  "recovery_key": "ed25519:...",
  "installing_primary_signing_key": "ed25519:...",
  "nonce_lanes": 8,
  "replacing": null,
  "signing": {
    "version": 1,
    "algorithm": "ed25519",
    "delegate": "<base64>",
    "digest": "<hex>",
    "nonce": 265547925000001,
    "nonce_index": 0,
    "max_block_height": 265555262
  }
}

Rebuild the activation delegate with near-kit from your identity, the constants above, and, this is the point, your own Primary Signing Key as the key being installed. Confirm installing_primary_signing_key is yours, and confirm the digest matches your rebuild. You are verifying that the key gaining authority is yours and that nothing else rides along.

Sign the digest raw with the Recovery Key and return it, with the delegate echoed back:

curl -s $BASE/dashboard/partner/wallet_keys/activation/authorize \
  -H "Content-Type: application/json" \
  -d '{"delegate": "<the base64 you verified>", "signature": "<base64>"}'

A delegate that is not the activation we prepared, or a signature that is not the Recovery Key's over it, returns 422 activation_rejected. On success, sending is enabled for every wallet you will ever create and the ceremony never repeats. Put the cold key away.