The object journey

Reading about a state machine is slower than driving one.

Everything on this page runs in your browser. It builds no transaction, signs nothing, and touches no Bitcoin network. What it does do is follow the same rules the indexer’s state engine follows, so what you see here is what the protocol would actually do.

0active

chapters

0

founding

yes

carrier

20,000 sats

key0

03054f9…aa2070

key1

034f9e1…ce23c6

address

bcrt1q883y…s50qflp

The record so far1 entry

CREATEseq 0

Both parties signed. The object exists at sequence 0 with no chapters yet.

Write a chapterAdds one entry. Keys stay the same.Rotate controlSwaps both keys. History is untouched.Close togetherBoth sign. Equal payouts.Broadcast the refundPre-signed by both. Needs 52,560 blocks.Spend it another wayThe object terminates.Start over

This is a teaching model. It runs entirely in this page, builds no transaction, and touches no Bitcoin network. The rules it follows are the ones insrc/protocol/state-engine.ts.

Three things to try

Press Write a chapter twice, then Rotate control. Watch the chapter count. It moves on the first two presses and then stops, while the sequence keeps climbing. That single behaviour is what makes control transferable without disturbing anything already written.

Start over, then press Broadcast the refund. The sequence does not move. Recovery is the one path that records the current sequence rather than advancing it, which means the numbers alone tell you whether an object ended by agreement in the moment or by one party broadcasting a refund the two of them had signed a year earlier.

Start over again and press Spend it another way. The object terminates immediately as EXITED_NONCANONICAL. Nothing is hidden and nothing is retried. The carrier no longer exists, so the object cannot still be in it.

Walk it one step at a time

Each of these pages takes a single transition, shows what the transaction has to look like, and explains what the protocol requires any reader of the chain to record.

• Found an object covers the CREATE that brings an object into existence and the founding window it may or may not land inside.
• Write a chapter covers MARK, the only operation that moves the chapter count.
• Rotate control covers replacing both keys without touching the history.
• Prepare recovery covers the timelocked exit the two of you sign in advance so that neither can later be denied it.
• Close together covers ending an object on purpose.

Then two pages about the reading side rather than the writing side:

• Agreement states shows what two independent indexers agreeing actually looks like.
• Failure scenarios lets you break that agreement seven different ways and see the surface close each time.

Where you are

01Discover TandemThe primitive in plain language, and the four promises it makes.02See what makes it differentWhat a shared object can do that a shared wallet and a shared account cannot.03Follow one object end to endFounding, chapters, a key rotation, and two different endings.04Understand two party controlThe 2 of 2 carrier, the sorted key pair, and why a spend is never silent.05Explore independent verificationWhy one indexer is an opinion and two indexers are evidence.06Try the protocol conceptsDrive an object through every transition and watch the state respond.07Integrate the APIRead the verified surface and handle the case where it closes.08Run the indexerBring up pipeline A, prove readiness, and keep mainnet gated.09Join the ecosystemOpen questions, unbuilt ideas, and how to contribute.

If you would rather understand the mechanics before playing with them, the object lifecycle states the same transitions in the specification’s own terms.