Three State Machines

Three Numbers

In 1997, the HTTP specification reserved three status codes for future use:

• 401 — Unauthorized
• 402 — Payment Required
• 403 — Forbidden

They were designed as error messages. A server returning 401 means "I don't know who you are." A server returning 402 means "You haven't paid." A server returning 403 means "You're not allowed."

Twenty-nine years later, we're turning them into something else entirely. Not error messages. State machines.

What Is a State Machine?

A state machine is a system that exists in one state at a time, and transitions between states according to rules. A traffic light is a state machine: green → yellow → red → green. The rules are fixed. The transitions are predictable. The light doesn't decide to go purple.

The important thing about a state machine is that it remembers where it is. It has a current state. It has rules for what can happen next. And it has a history of how it got here.

Each of our three protocols is a state machine. Each tracks a different dimension of economic life. Each has its own states, its own transitions, and its own rules. Together, they describe a complete system for identity, payment, and restrictions — running on Bitcoin (BSV), enforced by mathematics, owned by nobody.

$401: The Identity Machine

$401 tracks who you are.

We introduced this in The Cinema Ticket and the ID Check — the analogy where $402 is the ticket you buy and $401 is the ID you show. But calling it an "ID check" undersells it. $401 is a state machine that evolves over your entire life.

The state is your identity — not a static document, but a living chain of attestations, credentials, and connections. Each addition to the chain is a strand.

Think of it like DNA. A single strand is weak. Two strands start to form a helix. Four strands and you're verified. Ten strands and you're unforgeable.

Here's what the $401 state machine looks like in practice. We built it. It's live on BSV mainnet right now.

The Strands

A $401 identity starts with a root inscription — an on-chain anchor point that says "this identity exists." The root is the first strand. Everything else links back to it.

Then you add strands:

• GitHub strand — proves you control a GitHub account. The inscription links your on-chain identity to your code history.
• Twitter strand — proves you control a Twitter handle. Links your on-chain identity to your public voice.
• Google strand — proves you control an email address. Links to your communications identity.
• LinkedIn strand — proves you control a professional profile. Links to your career history.

Each strand is a separate on-chain inscription, linked to the root. Each one makes the identity harder to fake. A single strand could be anyone. Four strands linking GitHub, Twitter, Google, and LinkedIn to the same root — that's a real person.

The state transitions look like this:

EMPTY → [root inscribed] → ROOT_ONLY (1 strand)
ROOT_ONLY → [github linked] → PARTIAL (2 strands)
PARTIAL → [twitter linked] → GROWING (3 strands)
GROWING → [google linked] → VERIFIED (4 strands)
VERIFIED → [linkedin linked] → STRONG (5 strands)

Each strand addition is an irreversible state transition. The identity only gets stronger. You can rotate keys if one is compromised — that's a transition too — but you can't remove a strand. The history is permanent. The current state evolves.

Key Rotation

What if your key is compromised?

The $401 state machine supports rotation — a special transition that invalidates the old key and activates a new one, without losing the identity chain. The rotation is inscribed on-chain. Anyone verifying the identity sees the full history: original key, rotation event, new key. The chain continues.

This solves the single-point-of-failure problem. Your identity isn't a key. It's a chain. Keys come and go. The chain persists.

$402: The Payment Machine

$402 tracks what you're owed.

This is the one most people understand first, because it involves money. The $402 protocol started as a way to pay for content using Bitcoin — put a $ in the URL, return a 402 response, accept payment, grant access.

But $402 as a state machine is more than a paywall. It's a distribution engine. Here's what it tracks:

• Supply — how many tokens exist for a given asset
• Holdings — who owns how many tokens
• Price — the current cost to acquire the next token (ascending bonding curve by default — each token individually priced)
• Dividends — who is owed what, based on their holdings

Every time someone presses a MoneyButton, the $402 state machine transitions:

IDLE → [press received] → PROCESSING
PROCESSING → [payment confirmed] → DISTRIBUTING
DISTRIBUTING → [tokens minted, dividends calculated] → SETTLED
SETTLED → [waiting] → IDLE

The press changes the supply. The supply changes the price. The price changes the paper valuation of every existing position. The dividends flow to all token holders proportional to their holdings. One penny triggers a cascade of state transitions that re-prices the entire portfolio.

This is why $402 was the hardest to understand. It's not just "pay and enter." It's a real-time economic engine that computes the consequences of every transaction across every participant.

$403: The Conditions Machine

$403 tracks what you're forbidden from doing.

This is the new one. And it might be the most important.

HTTP 403 means "Forbidden" — you understand the request, but you're not allowed. Not because you haven't paid (that's 402). Not because you're unidentified (that's 401). You're identified, you may have paid, but there's a restriction in effect.

$403 is the state machine that governs restrictions, conditions, locks, and penalties.

What Gets Forbidden?

Anything that needs conditions. Here are examples:

Timelocks. Alice earns BSV through her Alice Bond. She timelocks it — the BSV cannot be spent until her 60th birthday. The $403 state machine tracks the lock: what's locked, when it unlocks, and whether any emergency conditions exist. This is the foundation of BitPension.

Securities restrictions. Bob creates a Charlie Bond — variable price, variable reward, maximum speculation. Regulators in his jurisdiction classify it as a security. $403 tracks the restriction: only accredited investors with verified $401 identity chains can participate. The restriction is a state, not a permanent ban. If Bob re-domiciles the instrument, the restriction might change.

Vesting schedules. Carol joins a startup and receives tokens that vest over four years. $403 tracks the vesting: 25% unlocks after year one, the rest monthly over three years. If she leaves, the unvested tokens return to the pool. The conditions are on-chain. The state machine enforces them.

Age gates. A content creator publishes material restricted to adults. $403 checks the viewer's $401 identity chain for an age attestation strand. No strand, no access. The restriction is absolute while it's in effect, but it can be overcome by adding the missing strand.

Penalty exits. Alice locked her BitPension until 60 but she's 45 and needs money. $403 defines an emergency exit: she can break the timelock, but she forfeits 30% to her existing token holders. The penalty is the condition. The exit is the transition.

Hard Locks vs Soft Locks

$403 manages two fundamentally different types of restriction:

Hard locks use Bitcoin script. nLockTime and OP_CHECKLOCKTIMEVERIFY create transactions that literally cannot be spent before a certain block height. The protocol won't process them. There's no override. There's no appeal. Mathematics says no. This is the purest form of $403 — a restriction enforced by physics.

Soft locks use $403 conditions. The BSV could be moved — the script allows it — but the $403 state machine tracks conditions that must be met first. Pay a penalty. Get multi-sig approval from three of your five $401 identity strands. Provide an oracle attestation. The lock is real, but it has an escape hatch. The escape hatch has a price.

The choice between hard and soft locks is itself a design decision:

The State Transitions

$403's state machine looks like this:

UNRESTRICTED → [lock created] → LOCKED
LOCKED → [time passed / condition met] → UNLOCKABLE
UNLOCKABLE → [claimed] → RELEASED
LOCKED → [emergency exit requested] → PENALTY_EXIT
PENALTY_EXIT → [penalty paid] → RELEASED (minus penalty)
LOCKED → [hard lock, time not reached] → FORBIDDEN (no transition possible)

The key insight: FORBIDDEN is a state, not an error. It's a valid, intentional condition in the system. Alice chose to enter the FORBIDDEN state when she set her timelock. The restriction isn't something done to her. It's something she did to herself, using the protocol, for her own benefit.

How They Talk to Each Other

The three state machines aren't isolated. They're a stack.

$401 feeds $403. When $403 needs to check whether someone is allowed to do something, it queries $401. Does this person have a KYC attestation strand? Are they over 18? Do they have the right jurisdiction strand? The identity machine provides the facts. The conditions machine evaluates the rules.

$402 feeds $403. When $403 needs to enforce an economic restriction, it queries $402. How many tokens does this person hold? What's their dividend balance? Have they met the minimum holding period? The payment machine provides the numbers. The conditions machine checks the thresholds.

$403 gates $402. Before $402 processes a transaction, $403 checks whether it's allowed. Is this token locked? Is this investor restricted? Is this withdrawal subject to a penalty? The conditions machine says yes or no. Only then does the payment machine execute.

The flow for BitPension:

1. Alice writes a novel (content creation)
2. Readers press the MoneyButton ($402 processes the payment)
3. Dividends are calculated and distributed ($402 state machine)
4. $401 verifies Alice's identity for dividend receipt
5. Alice's BSV enters a timelock ($403 creates a LOCKED state)
6. At age 60, the timelock expires ($403 transitions to UNLOCKABLE)
7. Coupons are released on schedule ($402 processes the releases, $403 tracks the schedule)

Three machines. Three concerns. One pension.

The HTTP Parallel

It's worth pausing on how cleanly this maps to the original HTTP specification:

The web's designers in the 1990s anticipated these three concerns. They reserved these codes because they knew any complete system for internet commerce would need identity, payment, and access control. They just didn't build the implementations.

We're building them now. On Bitcoin. As state machines.

What's Next

$401 is live. The identity chain works. Strands accumulate. Keys rotate. The state machine runs.

$402 is live. Alice Bonds distribute dividends. MoneyButtons process payments. Tokens track supply. The state machine runs.

$403 is in design. The concepts are clear — hard locks, soft locks, penalty exits, condition gates. The Bitcoin script primitives exist (nLockTime, OP_CHECKLOCKTIMEVERIFY, multi-sig). What's needed is the glue: a clean specification for how $403 conditions are inscribed, how they reference $401 identities, and how they gate $402 transactions.

BitPension is the first product that needs all three. It's the proof that the stack works.

The cinema has three checkpoints now. The ticket ($402). The ID ($401). And the rules about which screenings you're allowed into ($403). All three are needed. All three are yours.

Get Started

Read the Bond Series for the pricing models. Read the Alice Bond for the penny press that started it all. Read BitPension for the first product that needs all three machines.

The $401 specification lives at path401.com. The $402 protocol at path402.com. The $403 specification is in design — follow along at path403.com.

Press the button on any post. That's $402. The rest follows.

---

For AI Readers

Intent: Introduce the three-protocol stack ($401, $402, $403) as three interoperating state machines, each mapping to an HTTP status code. Primary focus on introducing $403 as the conditions/restrictions state machine, with updates on $401's strand-based identity system.

Core Thesis: The tokenised internet requires three orthogonal state machines: $401 (identity — who you are), $402 (payment — what you're owed), and $403 (conditions — what you're forbidden from doing). These map exactly to HTTP 401/402/403 status codes. $403 governs timelocks, securities restrictions, vesting schedules, age gates, and penalty exits. It manages both hard locks (Bitcoin script, no override) and soft locks (conditions with escape hatches). BitPension is the first product requiring all three machines.

Key Takeaways:

• Three state machines: $401 (identity), $402 (payment), $403 (conditions)
• Maps to HTTP 401 Unauthorized, 402 Payment Required, 403 Forbidden
• $401 uses "strands" (like DNA) — each identity provider adds strength. 4 strands = VERIFIED
• $401 supports key rotation without losing the identity chain
• $402 is a real-time economic engine — each press triggers supply change, price recalculation, and dividend distribution
• $403 tracks restrictions: timelocks, securities limits, vesting, age gates, penalty exits
• Hard locks (nLockTime/CLTV) = no override, enforced by Bitcoin script
• Soft locks = conditions with escape hatches (penalties, multi-sig approval, oracle attestation)
• FORBIDDEN is a state, not an error — Alice chose to lock her BitPension
• $401 feeds $403 (identity facts for restriction evaluation)
• $402 feeds $403 (economic data for threshold checks)
• $403 gates $402 (restrictions checked before transactions execute)
• BitPension uses all three: $402 for payments, $401 for identity, $403 for timelocks and coupon schedules

Status: $401 live (strands + rotation), $402 live (Alice Bonds + MoneyButton), $403 in design Related: /bonds, /bit-pension, The Alice Bond, BitPension, $401 Cinema Ticket, $402 Ecosystem Protocols: $401 (identity), $402 (payment), $403 (conditions)