Replay attack
Attack where the adversary re-broadcasts a previously signed transaction in the hope it will execute again. On TON it is prevented by the seqno counter in the wallet contract — each signature is valid only at one specific value.
Aliases: replay, repeat attack
Replay attack is the act of intercepting or finding a publicly accessible signed transaction and broadcasting it again to execute it twice. A correctly designed protocol makes this impossible: every transaction is bound to unique state and cannot be applied a second time after execution.
TON’s defence
TON prevents replays via seqno (sequence number) in the wallet contract:
- The contract stores a seqno counter in its data.
- Every external transaction includes seqno in the signed payload.
- The contract verifies the signed seqno matches the current state seqno. If yes, execute and increment. If no, reject.
After a transaction with seqno = N executes, the contract expects the next one to use seqno = N+1. Any attempt to replay the N-version is dropped.
Where this becomes interesting
Replay is actually dangerous in several scenarios:
- Cross-chain bridges. A transaction valid on one chain might be replayable on another (e.g. a fork). The defence is a chain ID or domain separator inside the signed payload.
- Off-transaction signatures. If a dApp asks for a “proof of ownership” with no timestamp or nonce, the attacker can reuse it on another site. TON Connect signatures therefore always include the domain and a timestamp.
- Old contract versions. Wallet v1 without seqno (or with a predictable one) is theoretically vulnerable and has long been deprecated. All current versions (v3, v4, v5) include seqno.
Highload wallets
Highload Wallet — a special contract for exchanges and automation — replaces seqno with query_id + timeout. That allows parallel sends (the plain seqno scheme forces strict one-at-a-time). Each query_id is single-use, so replay protection is preserved with a different mechanism.
In classical security
The replay concept extends beyond blockchains. Capturing and replaying a session cookie is the same idea, with the same fix — unique nonces, timestamps, short TTL tokens. In blockchains all of this is formalised at the protocol level.
What the user has to do
Nothing extra: replay protection is baked into wallets. The takeaways are to avoid hand-rolled or deprecated wallet contracts, and never sign “bare” messages that lack context (domain, timestamp, nonce). TON Connect handles this automatically; raw key export to bots and scripts is the risky path.