docs: PULSE — a standing unilateral exit for open-membership pools

[tiero]

Summary

Design specification for PULSE (Pooled Unilateral-exit via Lattice State Epochs): a way to give open-membership pool contracts — AMMs, lending pools, vaults — the same standing unilateral exit that ordinary Arkade VTXOs already have. Documentation only, no compiler changes. Supersedes #45.

The problem

An ordinary Arkade contract gives you a way out on your own. You write a tapscript leaf naming your key behind a CSV, and if the Operator disappears you broadcast it, wait out the timelock, and your funds land on L1. Nobody's permission required.

That construction needs to name its keys when the contract is instantiated — and a pool's membership is dynamic and unbounded, so there are no keys to name. In practice pool contracts ship with either no unilateral leaf at all, or one gated on a curator, which is custodial by another name. Pool exits today are transient: a cooperative redemption drains funds to per-holder VTXOs that each have a clean exit, but only while the Operator plays along.

So the gap is specific: a passive pool member — someone whose balance hasn't moved in weeks — has no standing way out. Their money is only as safe as the Operator's continued cooperation.

The idea

Keep a complete, fully pre-signed fire escape for every member at all times, and refresh it whenever anyone transacts.

The pool is one shared VTXO holding aggregate funds, plus a balance table. Each time someone deposits, withdraws, or trades, the parties actually involved — typically one or two, plus the Operator — run a short ceremony that re-signs an exit lattice: a tree of pre-signed transactions splitting the pool UTXO into one output per member at their current balance. Every member holds their own branch. Passive members sign nothing, ever, after joining. Whoever moves funds pays the coordination cost.

The trick that makes this safe without a covenant opcode: the pool's exit leaf is a single constant-size key plus a CSV, and the keys behind it are ephemeral and deleted once the lattice is signed. The lattice is then the only thing that can ever spend that leaf — a de facto covenant, built the same way Arkade's own VTXO trees are built. Operator vanishes, you broadcast your branch and walk out.

Two consequences shape everything else. Exit costs are bounded by how far the off-chain chain has run, so the pool periodically re-anchors on-chain (the heartbeat) — many cheap off-chain pulses between on-chain heartbeats, which is where "recurrent" comes from. And since a stale lattice would pay out old balances, exits sit behind a delay while ordinary transitions don't: anyone holding a newer state can always outrun an old one.

The parts that are actually hard

Who checks the numbers for people who weren't in the room? Every pulse publishes a signed attestation over the entire balance table, not just the parties transacting, and anyone at all can recompute two things from public data: that the lattice's outputs sum to the pool's value, and that they match the attested table. Fail either and conforming software treats the pulse as non-final and falls back to the last good one. A malformed or over-allocating lattice becomes a visible halt instead of a silent loss.

Can a live Operator simply stall your exit forever? This was the sharpest finding in review. Delayed exits versus undelayed transitions cuts both ways: a live Operator could keep displacing your exit indefinitely, carrying balances forward correctly each time so no fraud evidence ever exists. The fix is exit notices and eviction-with-payout — once you file a notice, the only valid way to displace your exit is a transaction that pays your full balance on-chain. Exit or payout; there is no third option, and refusing to do either is a visible stall that trips everyone else's auto-exit. This also defuses the mirror-image griefing attack, since broadcasting the current lattice now just means requesting your own payout.

What stops the Operator signing two contradictory histories? Signing nonces are pre-committed per epoch and role, so signing twice in one slot leaks the signer's key by plain Schnorr algebra — which lets anyone complete a pre-signed transaction that burns that signer's bond. Self-executing, no judges, no token, ordinary Bitcoin.

What it honestly does not give you

The document is explicit about this rather than burying it, and a reader should know before evaluating:

• Getting out is yours alone (1-of-N). You hold a pre-signed lattice; you, or any watchtower, can broadcast it. Operator or emulator shutdown means freeze, never theft.
• The amount on your slot is enforced, not trustless. When you're passive, the number is written by the Operator plus whoever is transacting — a set that excludes you and can be as small as two. An honest threshold (enclaves refusing invalid pulses) or a bond backstops it, but that is committee/hardware trust, not consensus.

That split is deliberate, and §13.2 states why it's unavoidable: with non-interactive passive members and no covenant opcode, amount safety must rest on a trusted layer. Covenant-grade trustlessness needs a fork (§12.2 sketches what changes under the Great Script Restoration). Absent one, trustless-mechanism / enforced-amount is the end state.

What formal verification caught

An independent pass built TLA+ models of the ceremony and the timed exit race and Lean proofs of the signature algebra. It surfaced A24, a CRITICAL flaw in the spec as previously written: nonce commitments were indexed per epoch, but the Operator threshold signs two artifacts per epoch. Two messages under one nonce is exactly the key-extraction condition, so a faithful implementation would have leaked its own key and burned its own bond during entirely honest operation — no attacker, no crash. Nonces are now indexed per (epoch, role). Four further claims were tightened where the prose said slightly more than it could support.

That pass's own limits are recorded in §0 too, so nothing reads as more verified than it is: one ordering invariant is enforced by the model's construction rather than independently falsified, the timelock inequality is a property of the chosen parameters rather than of the protocol, and the trilemma remains unformalized.

Reading order

§1 is a plain-language walkthrough with no math. §7 is the protocol proper. §10 is the 24-finding adversarial table, which is the fastest way to judge whether the design has been pushed on hard enough. §13 is the honest security accounting. §0 logs how the document evolved.

Draft, and intended as input to a whitepaper. The compiler-surface section (§11) is explicitly future work and touches no supervised zones.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DyA8J3GnnE55mvBWX4wHnT

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Playground Preview

A live preview of this PR's playground is available at:
https://arkade-os.github.io/compiler/pr-previews/pr-91/

Built from commit ebc14637822f488ad7198827cf97d2f60a729c3f · Workflow run