sign object. Its scheme tells you which fields are filled in, what the user signs, and which fields you submit. Branch on sign.scheme, not on chain.
Summary
solana_ed25519
The user signs the decoded bytes with their ed25519 key. You submit the 64-byte signature, base58-encoded, as
signature. Bitnob adds the fee payer’s signature and broadcasts.
Send your first sponsored transfer has working code.
evm_7702
EVM transfers need two signatures from the same from key:
Submit both as
signatures.authorization and signatures.witness. Each is a 0x-prefixed 65-byte signature, which is r, s, and v concatenated.
The quote response also returns router_version, the router contract version the quote was built against. Leave router_version out of your request to get the chain’s default.
See Sign on EVM chains.
tron_router
The user signs
digest with their secp256k1 key, and you submit it as tron_signature. When approve is present, the user also signs approve.digest, and you submit that as tron_approve_signature in the same call. Submitting only tron_signature when approve is present returns 422.
The approval lets Bitnob’s router contract move that token from the sender’s address. It is needed once per sender per token, and the quoted fee already covers its cost. If the sender’s account has never been used on chain, Bitnob activates it first.
See Sign on Tron.
Where signing happens
The user’s key never touches your servers or Bitnob’s. In production, the signing step runs in the user’s wallet: a browser extension, a mobile wallet, or your own self-custody app. Your backend requests the quote, passes thesign payload to the client, and receives the signature back.
The examples in these guides sign with a local test key, to keep them short. Use them in sandbox, and replace the signing step with your wallet integration in production.