Signature

Signature is the short byte string a wallet attaches to every transaction so that network validators can confirm it really came from that address. TON uses Ed25519: 64-byte signatures, fast to generate, fast to verify, and resistant to weak random-number generators at verification time (deterministic signing).

How it is produced

The Ed25519 algorithm takes a message and a private key and outputs a 64-byte signature:

signature = Ed25519_sign(private_key, message)

In TON the “message” is the hash of a cell that encodes an external transaction (recipient, amount, payload). The signature is attached to the external message that goes into the mempool.

How it is verified

Any network node — validator, lite server, or passive observer — runs:

ok = Ed25519_verify(public_key, signature, message)

If ok is true, the transaction is authentic and goes into a block. If false, it is dropped.

The public key is read from the wallet contract’s state, where it was written at deploy time. Nodes can therefore verify every transaction without any access to user secrets.

Comparison with other schemes

• secp256k1 (Bitcoin, Ethereum). Different curve, 65-byte signatures (with recovery byte), needs strong randomness during signing.
• secp256r1 (NIST P-256). Used in Apple Secure Enclave and YubiKey.
• Ed25519 (TON). Modern Curve25519-based scheme, deterministic, side-channel resistant. Effectively the 2020s best practice.

Pitfalls

Signing a raw byte array that can be replayed in multiple contexts is a vulnerability. The correct TON pattern is to sign a cell hash that includes context (sender, message type, seqno). Without seqno the same transaction could be replayed (a replay attack).

Never sign arbitrary “messages” outside the wallet. If a dApp connected through TON Connect asks for a signature over a “verification string”, make sure the string carries a domain prefix — otherwise the signature could be reused in another context.