Skip to main content
How token transactions actually work under the hood.

​
The basics

A token transaction moves tokens from inputs to outputs. Three parties involved:
  1. You (the wallet): construct and sign the transaction
  2. Spark Operators: validate, co-sign, and commit
  3. Watchtowers: watch for cheaters trying to double-spend on L1
The key thing: operators never have unilateral control. Every transaction needs your signature. They witness and enforce, but they can’t move your tokens without you.

​
The flow

1. You build the transaction
   - Which outputs to spend
   - Who gets what
   - Sign it

2. Send to operators

3. Operators validate
   - Check your signatures
   - Check you own the inputs
   - Reserve revocation keys

4. Operators fill in the final details
   - Revocation commitments (for double-spend protection)
   - Withdrawal parameters (for L1 exit)

5. Operators commit
   - Threshold signs off
   - Watchtowers updated

6. Done
   - You get the final transaction
   - Recipient can spend immediately
One call handles the whole thing. It’s atomic. Either everything succeeds or nothing does.

​
Transaction types

Mint: Issuer creates new tokens. No inputs spent. Just issuer signature authorizing creation. Transfer: Move tokens between owners. Inputs must equal outputs. Create: Register a new token type. Define name, ticker, decimals, max supply.

​
Revocation: how double-spend protection works

This is the clever part. When you receive tokens, each output has a “revocation commitment”. This is a public key where the private key is split among operators. Nobody knows the full key. When you spend those tokens, operators release their key shares to you. Now you can reconstruct the full “revocation key” for the outputs you just spent. Why does this matter? If you try to cheat by broadcasting old outputs to L1:
  • Watchtowers see it
  • They have the revocation key (you gave it to them when you spent)
  • They sweep your funds immediately
  • You lose everything
The economic incentive is simple: cheating costs more than you could gain.

​
Validity window

Transactions expire. You have up to 300 seconds (5 minutes) from when you create a transaction to when operators commit it. After that, it’s rejected and you have to start over. This prevents stale transactions from clogging the system.

​
What can go wrong

ProblemWhat happened
Insufficient balanceYou don’t have enough tokens
Output already spentSomeone else spent it first
Invalid signatureWrong key
FrozenIssuer froze your address
Transaction expiredTook too long, try again

​
Finality

Once operators commit, it’s done. Instant. Final. The recipient can spend immediately. No confirmations to wait for. The only “confirmation” that matters is the threshold of operators agreeing. Once they do, the transaction is irreversible at the Spark level.