Transaction Lifecycle

How token transactions actually work under the hood.

The basics

A token transaction moves tokens from inputs to outputs. Three parties involved:

You (the wallet): construct and sign the transaction
Spark Operators: validate, co-sign, and commit
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

Problem	What happened
Insufficient balance	You don’t have enough tokens
Output already spent	Someone else spent it first
Invalid signature	Wrong key
Frozen	Issuer froze your address
Transaction expired	Took 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.

Introduction

Design