The Conditions Machine — Programmable Permissions for the Open Web
A state machine for permissions, restrictions, and programmable conditions — enforced on-chain, earned through Proof-of-Work.
Note: This is a cursory theoretical draft for discussion. The $403 protocol is designed but not yet implemented. Nothing in this document constitutes legal advice, financial advice, or a binding specification. Published for feedback and collaboration.
We propose $403, a programmable conditions protocol that runs as an on-chain state machine on BSV. Where $401 handles identity (who you are) and $402 handles payment (what you pay), $403 handles permissions — what you may or may not do, and under what conditions. Conditions are expressed as deterministic rules, enforced by miners and indexers, and earned through Proof-of-Work mining via a BSV-21 PoW20 hash-to-mint sCrypt contract. The protocol addresses multiple permission classes: securities compliance, age-gating, self-imposed restrictions (savings, pensions), time-locks, geographic restrictions, identity-gated access, and arbitrary programmable conditions. Indexers who validate condition state perform Proof of Indexing — verifiable work that earns them $403 tokens and ensures the network remains honest.
HTTP 403 means “Forbidden” — the server understood the request but refuses to authorize it. This is the missing piece in the $40x trinity:
Who are you? Root key, OAuth strands, attestations. The subject of every condition.
What do you pay? Tokenized access, serving revenue, economic incentives. The currency of every condition.
What are you allowed to do? Programmable rules, restrictions, gates. The logic layer.
Without $403, permissions are ad-hoc: hardcoded in application logic, unauditable, unportable. With $403, permissions become first-class on-chain objects — inspectable, composable, transferable, and enforced by the network itself.
Every $403 condition is a finite state machine (FSM) inscribed on-chain. A condition has states, transitions, and guards. Transitions fire when guards evaluate to true. Guards can reference: $401 identity data, $402 payment state, block height, timestamps, external oracle data, or other conditions.
Conditions are composable. A content platform might require $403/age-gate/18+ AND $403/geo/UK AND $401.strands >= 2. Each condition evaluates independently; the conjunction is itself a condition.
The $403 protocol must handle fundamentally different categories of permission. Each class has distinct legal, ethical, and technical requirements:
Theory: Securities conditions are RESTRICTIVE — they default to FORBIDDEN and require explicit qualification. The state machine starts LOCKED. Guards reference $401 identity strands (KYC provider attestation, accredited investor strand, jurisdiction strand). These conditions are typically imposed by the token ISSUER and cannot be removed by the holder.
Theory: Age conditions require a TRUSTED ATTESTOR — someone who verified the age claim. This could be a government ID verification service ($401 strand), a parent/guardian co-signature, or a self-declaration (weakest). The condition state machine has a one-way ratchet: once age-verified, the state doesn't revert (you don't get younger). Parental overrides introduce a second key with REVOKE authority.
Theory: Self-imposed conditions are the most philosophically interesting. The holder VOLUNTARILY restricts their own future self. This requires the condition to be IRREVOCABLE once set — otherwise the restriction is meaningless. The sCrypt contract enforces this: once a savings lock is inscribed, no key can unlock it before the specified block height. This is commitment technology — using the blockchain as a pre-commitment device. Pension conditions use periodic unlock windows: the state machine cycles through LOCKED → WITHDRAWAL_WINDOW → LOCKED, triggered by block height.
Theory: Geographic conditions reference $401 jurisdiction strands or IP-based attestations. These are DYNAMIC — a user's jurisdiction can change, and the condition must re-evaluate. The state machine supports REVOCATION: if a user moves to a sanctioned jurisdiction, their access transitions from UNLOCKED back to LOCKED. Oracle data (IP geolocation services) can provide attestation inputs.
Theory: These conditions compose directly with $401. The guard expression evaluates the identity graph: strand count, specific providers, attestation strength (self vs. service), reputation scores. This is the lightest class — no legal compliance burden, just trust calibration.
Theory: Temporal conditions are the simplest class — guards reference only block height or timestamp. No external data, no identity checks, purely deterministic. Vesting schedules use a STAGED state machine: CLIFF → VESTING → VESTED, with partial unlock at each transition. The sCrypt contract can express this directly as a spending condition on the UTXO.
Theory: Composite conditions are conditions-of-conditions. The state machine evaluates sub-conditions as inputs. This enables arbitrary business logic: escrow (condition: both parties sign), insurance (condition: oracle attests event), governance (condition: quorum of token holders vote). The $403 condition language is intentionally NOT Turing-complete — it is a restricted, deterministic rule language that can always be evaluated in bounded time.
The $403 token is a BSV-21 token deployed via a PoW20 hash-to-mint sCrypt contract, identical in structure to the $402 token.
Mining: Hash-to-mint. Submit valid PoW to the contract, receive $403 tokens. Same mechanism as $402.
Indexing: Validate condition state transitions. Proof of Indexing earns $403.
Staking: Stake $403 to run a condition evaluation node. Earn fees from condition checks.
Conditions are only useful if they are correctly evaluated. An indexer that claims “condition X is UNLOCKED” must prove it did the work to arrive at that state. This is Proof of Indexing (PoI).
Indexer processes a batch of condition state transitions (e.g., 1000 conditions evaluated against new block data).
Indexer constructs a Merkle tree of all (condition_id, previous_state, new_state, guard_inputs) tuples.
Indexer inscribes the Merkle root on-chain with a PoW nonce (meeting the current difficulty target).
Any challenger can request a Merkle proof for any specific condition. The indexer must produce it or lose stake.
Valid PoI submissions earn $403 tokens. Invalid submissions (proven by challenge) slash stake.
Proof of Indexing combines Proof-of-Work (the nonce) with Proof-of-Correct-Computation (the Merkle tree of state transitions). This means indexers must both expend energy (unforgeable cost) and produce correct results (challengeable output). Neither alone is sufficient. Together they create an honest conditions network.
Each $403 condition is an sCrypt smart contract on BSV. The contract encodes:
The contract lives as a UTXO. Each state transition spends the current UTXO and creates a new one with the updated state. This creates an immutable, auditable chain of condition state changes. The irrevocable flag is critical for self-imposed restrictions: once set, even the issuer cannot bypass the condition.
The $403 security model rests on three pillars:
Conditions are enforced by Bitcoin Script (sCrypt contracts). Miners validate every state transition. An invalid transition is an invalid transaction — it will not be mined. This is the strongest possible enforcement: the same mechanism that prevents double-spending prevents condition violations.
Indexers who evaluate conditions must prove their work. The Merkle tree of state transitions is challengeable. False claims lose stake. This creates economic incentive for honest indexing — the same game theory as Bitcoin mining.
Self-imposed restrictions are cryptographically irrevocable. No key, no social recovery, no admin override. The script simply will not execute until the condition is met. This is what makes $403 useful for commitment devices: savings locks, pension plans, vesting schedules. If the creator could bypass them, they would be worthless.
The three protocols form a complete stack:
Request flow: A user requests access to a $402 resource. The $402 contract checks $403 conditions before processing payment. $403 conditions reference $401 identity data for evaluation.
Example: Alice wants to buy $TOKEN. $403 checks: Is Alice's $401 identity verified (2+ strands)? Is she in an approved jurisdiction? Has she passed accredited investor verification? If all conditions evaluate to UNLOCKED, the $402 payment proceeds.
Composability: Any $402 token can reference any number of $403 conditions. Conditions can reference other conditions. The entire permission graph is on-chain, auditable, and deterministic.
This draft intentionally leaves several questions unresolved:
$403 completes the $40x protocol stack. Identity ($401) tells us who. Payment ($402) tells us how much. Conditions ($403) tell us whether.
The key insight is that permissions are state machines. They have states (LOCKED, UNLOCKED, EXPIRED). They have transitions (guards that evaluate to true or false). They have effects (granting or revoking access). And critically, some of them must be irrevocable — commitments that even the creator cannot undo.
By running conditions as on-chain state machines, enforced by sCrypt contracts and validated by Proof-of-Indexing, we create a permission layer that is transparent, auditable, composable, and unstoppable.
This is a draft. The protocol is designed. The implementation is next.
$403 Conditions Machine — Draft v0.1.0 — February 2026 — @b0ase
Not legal advice. Not financial advice. Not a final specification.