Signing for autonomous callers

Building a transaction and authorising one are different operations with different privileges, and the SDKs already enforce the split: they hand back objects with an empty proofs array. That is not an inconvenience to work around. It is the shape that lets software decide what should happen without ever being able to make it happen.

// Process A — no key material anywhere in it.
const proposal = buildInvoke({ dApp, call, senderPublicKey });
 
// Process B — holds the key, and decides.
if (policy.allows(proposal)) {
  const signed = sign(proposal, key);
  await broadcast(signed);
}

Everything downstream follows from where you draw that line. A program on the left of it can be given wide latitude, because the worst it can produce is a proposal that gets declined. A program that also holds the key on the right has exactly the authority of the key, and no policy written in your own code constrains an attacker who reaches it.

• @decentralchain/signer — the high-level signing interface. Published at 1.1.0-beta. Treat the API as unstable and pin it.
• @decentralchain/ts-lib-crypto 2.0.0 — key generation, address derivation, and the primitives. Exports keyPair, publicKey, privateKey, signBytes, verifySignature, randomSeed, and seedWordsList.
• @decentralchain/signature-adapter 6.1.7 — adapts several signing back ends to one interface.
• @decentralchain/ledger 5.1.0 — hardware signing.

Pick by what you are willing to lose if the process is compromised, not by what is convenient to build.

• Operator-held seed. Fully autonomous, runs unattended, and settles without anyone awake. The key sits in the same blast radius as the agent, so scope the account to what it is allowed to lose and fund it accordingly. This is the only pattern that can currently withdraw across the Solana bridge.
• Hardware signer. The key never leaves the device and a person approves each call, so a compromised agent produces declined proposals rather than losses. It cannot run unattended, and it cannot call burnToken on the bridge today.
• Human in the loop via Cubensis Connect. The program proposes and a browser wallet confirms. Good for agents that draft rarely and act visibly; poor for anything on a schedule. Same bridge limitation applies.

The Solana bridge has contracts and validators live on mainnet, and the frontend signs nothing, holds no keys, and runs no relayer. Deposits are Solana transactions; a withdrawal is a burnToken call on DecentralChain.

BTC, cbBTC and BONK are registered but unusable, and the interface filters them out. The bridge exists on mainnet only; there is no testnet deployment to rehearse against.

SOL and JitoSOL carry 9 decimals on Solana and 8 on DecentralChain. Assuming they match is wrong by a factor of ten, in whichever direction hurts more. Read the value from GET /tokens per asset rather than hard-coding it, and assert on it in the same place you build the amount.

This belongs in a signing document rather than a reference table because signing is where the mistake stops being recoverable.