DEFINE AUTHORIZATION
Specify the application, network, action, account, unique nonce, expiry, and target program.
Protect signed authorizations with explicit context, nonce validation, expiration rules, and replay-resistant verification patterns.
Bind intent to one application context.
Prevent a valid authorization from being consumed twice.
Verify the whole payload, not just its signature.
A signature is only one input. Security lives in the validation order and state that surrounds it.
Specify the application, network, action, account, unique nonce, expiry, and target program.
Sign a canonical payload that carries the required context fields—not an ambiguous message.
Check signature, domain, network, account, nonce freshness, expiry, action, and target.
Persist the nonce or authorization ID. A valid authorization cannot be used again.
{
"context": {
"domain": "replayzero.online",
"network": "solana:mainnet"
},
"authorization": {
"account": "demo-wallet-7F3A...91C2",
"action": "TRANSFER_AUTHORIZATION",
"target": "program:replayzero.v1",
"nonce": "rz-2026-000184",
"expiresAt": "2026-11-04T18:00:00.000Z"
}
}Each test runs against the generated payload and the in-memory consumed nonce registry. Every result is simulation data.
Expected domain, network, nonce, and expiry.
Swap the application domain to malicious.example.
Swap the network identifier to ethereum:1.
Submit an authorization ID already consumed.
A compact reference for engineers designing application-level authorizations and Solana integrations.
Solana transactions use protocol-level signatures plus a recent blockhash or durable nonce for transaction processing. That does not make every transaction inherently vulnerable to cross-network replay.
Wallet-signed application messages are a separate surface. Bind them to an application-specific domain, validate program instructions, use a nonce or sequence number, and define expiry. Durable nonces solve transaction freshness; they do not replace application-level authorization state.