Skip to content

Instantly share code, notes, and snippets.

@jaybny
Last active August 18, 2026 15:12
Show Gist options
  • Select an option

  • Save jaybny/0603ac93fbd75f1fde661265d8a4c2ec to your computer and use it in GitHub Desktop.

Select an option

Save jaybny/0603ac93fbd75f1fde661265d8a4c2ec to your computer and use it in GitHub Desktop.
ProofNet Live

Sidepit ProofNet R2 is live: the exchange now echoes itself

There's an exchange running on real Bitcoin right now where the fastest machine in the room has no advantage over yours.

Every order on Sidepit lands in a one-second deterministic auction. Inside that second, the best price wins - not the shortest wire, not the closest colo, not the fastest FPGA. The race that decides every other market simply does not exist here.

And as of today, this exchange does something no other venue does: it explains itself, continuously, while it runs. We call it the CEX echo. You send a signed request; you see a receipt instantly; the request enters the auction; the engine applies the rules; and the exchange pairs your exact intent with its exact result and publishes the complete new truth of your account - every second, through open, close, and even a controlled restart. No polling, no guessing, no "did that go through?" Ever.

Your Bitcoin address is your account - no signup, no email, no API-key ceremony. Your AI agent gets its own key: one that can trade for you but can NEVER withdraw. That's not a policy promise - it's enforced by the protocol itself. Appoint it in one click, revoke it in one click, and your money key never leaves your own wallet extension.

ProofNet R1 put real Bitcoin, one-second auctions, and delegated trading into production. R2 completes the story: complete account state, an end-to-end unlock lifecycle, and an exchange that narrates every consequence of every action back to you as it happens.

Want proof before trust? Point your agent at https://github.com/sidepit/Public-API and say: "read AGENTS.md and show me the live quote." Two minutes. No credentials. Live production data.

For a customer, ProofNet can now answer the most important question in trading: "I sent something - what happened?" For an agent, delegation is a durable, revocable identity instead of an API key with vague permissions. For a market maker, the protocol feeds never stop. For the next Sidepit node, bootstrap-plus-tail is now a concrete protocol. The rest of this post is the technical story of how.

One account, one continuous story

For the customer, one Bitcoin address now carries the account from deposit through trading, delegation, and unlock.

Your Bitcoin address is still your Sidepit account. You create the key locally, fund the address, and deposit Bitcoin. The exchange learns the public identity from the Bitcoin lock and turns it into trading balance.

From there, the same account can:

  • trade directly with its owner key;
  • appoint multiple trading-only delegate keys;
  • revoke a delegate without rotating the money key;
  • place, cancel, and cancel-replace orders across multiple contracts;
  • request an explicit unlock amount or the maximum currently available; and
  • follow that unlock from request to reservation to Bitcoin TXID and completion.

Your agent gets its own key, trades continuously, and can never withdraw. That restriction is enforced by the protocol, not by policy.

Delegate authority remains narrow at the protocol layer. A delegate can trade for its account. It cannot appoint another delegate, revoke authority, or request an unlock.

Every account operation has one operation ID derived from the Sidepit ID and the signed transaction timestamp. The first customer- visible state is a pending receipt. The same ID later becomes accepted or rejected. Terminal state wins; an old pending observation cannot resurrect a revoked delegate or a completed request.

For unlocks, the customer-facing lifecycle is explicit:

PENDING -> RESERVED -> PROCESSING -> COMPLETED

Accepted reservations reduce available funds once. Completion joins the exact operation ID, amount, and Bitcoin TXID. Replays are idempotent, and an unrelated Bitcoin outflow cannot silently retire the wrong request.

Web onboarding and account operations

The owner can authorize an agent, revoke it, and request an unlock without moving sensitive wallet credentials outside the extension.

Beta access remains code-gated. Reply for a beta code, then connect the UniSat Chrome extension with a Native SegWit bc1q address. That connected address becomes the customer’s Sidepit ID. Account authorizations are signed through UniSat; sensitive wallet credentials remain inside the extension.

To authorize delegated trading, a local trading agent generates a Sidepit delegate identity and gives the customer its 66-character public key. The customer selects Authorize trading agent, pastes the key, confirms the derived agent Sidepit ID, and signs.

The resulting delegate can trade for the account but cannot unlock funds or manage other delegates. Active agents can be revoked from the same web interface.

Withdrawals use the same owner-controlled signing boundary. Under Sidepit Account, select Unlock funds, enter an integer amount in sats or choose MAX, confirm the Sidepit ID, and sign. Funds always return to that same Sidepit address; there is no destination field to mistype.

The web interface follows the request through receipt, RESERVED, PROCESSING, COMPLETED, or rejection. When a Bitcoin TXID becomes available, the customer gets both an explorer link and a copyable transaction ID.

SP1 does the exchange work. SP0 explains what happened.

A client no longer has to infer success from silence, a missing rejection, or stale state.

Sidepit processes orders in one-second auction epochs. Within an epoch, price priority matters; arriving a few microseconds earlier does not buy queue priority over a better price.

ProofNet R2 makes the boundary between calculation and observation explicit:

  1. EpochOrders is the ordered intent for one epoch.
  2. SP1 applies matching, fills, cancels, account operations, and margin.
  3. SP1 produces one matching LiveShare containing the result.
  4. SP0 pairs the two by epoch.
  5. The reducer finalizes receipts and folds the complete state for dirty accounts.

SP0 does not infer success from a missing rejection, peek into a thread-owned map, or invent an account result before SP1 produces it. It observes the input and the result.

This separation also removed a class of display bugs where the engine was correct but the customer view stayed stale until the executable restarted.

A complete account feed, not another polling API

A replica can now stay current without polling every account or guessing whether a quiet interval means missed data.

Port 12131 now publishes complete AccountMarginState replacements for the accounts changed by an epoch. Quiet ticks still carry an epoch watermark, so a replica can tell the difference between “nothing changed” and “I missed data.”

The replacement includes the state clients actually need to reason about an account:

  • Sidepit ID and public key;
  • Bitcoin net locked;
  • available balance and available margin;
  • contract and per-ticker positions;
  • working-order margin and open-order counts;
  • active delegates and their public keys; and
  • pending unlock reservations.

The feed is dirty-account-only. We do not broadcast the full account map every second, and clients do not need to query port 12125 account by account every five minutes.

Replicas bootstrap from the accumulated snapshot and then follow 12131. Snapshot frames use explicit START, DATA, and STOP cadence, carry their epoch and correlation context, sort account IDs deterministically, and stay inside the established 1,450-byte packet ceiling. Existing order-book snapshot clients remain on the default BOOK path; complete account state is the additive MARGIN path.

OPEN and CLOSED are parts of the same machine

Clients that connected during an open session can keep their NNG subscription sockets alive across schedule boundaries.

The exchange hot path has almost no shutdown logic by design. Main owns the schedule and sleeps until the next boundary. SP1 owns the exchange and margin map. Forever Server owns the customer-facing in-memory projection.

During OPEN, every one-second epoch follows the paired intent/result reducer. During CLOSED, main grants Forever Server a bounded account-loop lease. That loop drains new Bitcoin locks and signed account operations, applies terminal results, reconciles completed unlocks, refreshes account state, and publishes the same complete replacement shape before handing control back.

The next PendingOpen cannot race ahead of unfinished account work. A late startup still performs one mandatory final pass. Recovery must complete its handoff before the first live epoch is allowed to fire.

This was tested the unpleasant way. A crash-recovery harness caught the first live epoch arriving while the previous share slot was still occupied. The fix did not make the slot lossy. It gated late open on the completed recovery handoff and preserved the rule that an epoch result is never silently dropped.

The target behavior is intentionally boring:

OPEN -> CLOSE -> OPEN -> CLOSE -> OPEN -> CLOSE -> ...

Clients that connected during an open session can keep their NNG subscription sockets alive across those boundaries.

Margin and money state now survive the same round trip

Balances, margin, working orders, and unlock reservations now survive the path from engine state to customer view.

Several fixes in this release look small in isolation but close important accounting loops:

  • net_locked survives live margin snapshots instead of disappearing during a state conversion;
  • working-order buy and sell margin caches are rebuilt at pre-open from the persisted positions and order counts;
  • canceling an order releases its cached working-order requirement;
  • restricted accounts continue using the more conservative initial-margin rule for exposure-increasing working orders;
  • accepted unlocks reserve balance and margin exactly once; and
  • a landed Bitcoin outflow consumes the reserved unlock bucket first, then debits only unmatched spillover.

The engine supports multiple tickers in the same epoch. Order feeds retain the more_in_epoch framing needed to distinguish “another ticker follows” from “this auction is complete.”

Receipts became a real product surface

A customer can see that a request arrived, then follow the same operation ID to its terminal result.

Port 12125 is no longer merely a database-shaped position query. It is the customer’s account view.

When Sidepit accepts a signed delegate, revoke, or unlock request at the door, the account can see that receipt immediately as is_pending=true. That is a promise only that the request was received - not that margin rules accepted it.

After the request is processed, the same operation ID is finalized. Successful delegate state appears in the settled delegate records. Rejections retain their reason. Unlock progress appears in lifecycle records with the Bitcoin TXID when one exists.

This gives clients a clean rule:

Show pending requests as receipts. Use terminal records and complete account state as truth.

That rule works for a human using the TUI, a new agent following the public Sidepit skill, and a market maker maintaining its own replica.

Recovery is moving toward hashes all the way down

For the next recovery layer, complete state can be named, copied, and verified by hash.

ProofNet R2 also ships the first Protoblock bootstrap layers.

At a LongEpoch, complete account states are serialized deterministically, written under their content hashes, assembled into a Merkle tree, and published through one account-state root. Resting orders have a parallel shadow tree: order leaves roll into price levels, ten-price segments, ticker metadata, and an exchange book root.

Immutable leaves and tree nodes are write-once. Repeating an identical checkpoint reuses the existing content. A changed account or partially filled order rewrites only its leaf and ancestors. Protobuf map insertion order cannot change the root.

The one-second EpochOrders journal moved to SP0 and is persisted before the corresponding result is accepted for settlement or publication. If that write fails, the process refuses to pretend the epoch is recoverable.

The current live recovery path still uses the exchange’s established durable stores and epoch replay. The content-addressed roots are the next recovery substrate: complete state that can be named, copied, verified, and eventually served without trusting a database directory.

Built for operators, not only test agents

A human operator can now drive and inspect the same lifecycle without rebuilding a giant grep command.

This release also turns months of internal harness work into commands a human can use:

  • create durable owner and delegate identities without overwriting an existing key;
  • fund test identities through the native Bitcoin tooling;
  • enroll or revoke a delegate from spxc;
  • submit an unlock request from spxc or the web interface;
  • list all accounts from the private account snapshot;
  • inspect delegations, unlocks, locks, account operations, and state transitions without rebuilding a giant grep command; and
  • work with SPX, SPXC, and the operator tools in one VS Code workspace while compiling each target separately.

Startup work was bounded as well. The TPO history loader no longer reconstructs an unlimited lifetime of irrelevant terminal orders just to answer today’s account query.

The release, by the numbers

The scale of the release is visible in the diff and in the paths exercised before launch.

From the previous production delegation base to the deployed ProofNet R2 merge:

  • 154 commits
  • 126 files changed
  • 27,765 insertions and 5,279 deletions
  • one-second auction epochs
  • 1,450-byte bounded snapshot frames
  • more than 9,000 C++ assertions in the current test host
  • manual OPEN/CLOSE cycling, controlled CLOSED restart, intraday crash recovery, and replay against a copy of the production LevelDB state

The deployed release was built from merge commit 840113d92a7cca5d5fae410f2ed7dbe746f4216a. The installed production binary was verified byte-for-byte against the release build before launch.

What this unlocks

For a new customer, Sidepit can now answer the most important question: “I sent something - what happened?”

For an agent, delegation is a durable, revocable trading identity instead of an API key with vague permissions.

For a market maker, the order, price, rejection, epoch, and account feeds are continuous protocol surfaces rather than a collection of polling calls.

For the next Sidepit node, bootstrap plus tail is now a concrete protocol: take a complete snapshot, remember its epoch, follow dirty replacements, and resync if the watermarks show a gap.

The exchange engine was already matching orders. ProofNet R2 makes the entire system explain itself while it runs.

Start here: https://github.com/sidepit/Public-API Wire contract: https://github.com/sidepit/Public-API-Data Exchange lineage: https://github.com/sidepit/sp1-cex-echo Docs: https://docs.sidepit.com

The exchange explains itself. Now the next node can follow. 🟧

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment