docs: add PULSE protocol specification for recurrent pool exits

[tiero]

Summary

Add comprehensive design specification for PULSE (Pooled Unilateral-exit via Lattice State Epochs), a protocol for enabling standing unilateral exits in open-membership pool contracts on Arkade through recurrent state updates and pre-signed exit lattices.

Overview

This document defines a complete protocol lifecycle for pool exits that addresses the gap in today's exit compilation: passive pool members currently have no standing unilateral exit when using open-membership recursive covenants (AMMs, lending pools, etc.).

Key sections

• Motivation & design principles — why N-of-N exit leaves fail for dynamic pools, and the four core design tenets (transactor-borne interactivity, state-aware data availability, finality on state updates, bounded lifetime)
• Protocol lifecycle — detailed ceremony ordering for genesis, pulses, heartbeats, unilateral exits, and expiry, with explicit trust model for each role (passive members, transacting parties, Operator, watchtowers)
• Exit mechanism — the exit leaf structure (<PULSE_KEY> OP_CHECKSIG <exit> OP_CHECKSEQUENCEVERIFY), pre-signed lattice trees, and chain-extension dominance for invalidating stale states
• Invalidation model — three threat classes (stale lattice, commitment withholding, fresh collusion) and their defenses
• Bond and enforcement — judicial federation bond for deterring collusion-theft, independent of the emulator, with objective equivocation evidence
• Attack analysis — thirteen adversarial findings (A1–A13) that shaped the spec, with severity and resolution for each
• Compiler surface (future work) — proposed grammar extensions for recurrent exit mode and ABI requirements
• GSR annex — how the Great Script Restoration would upgrade each baseline characteristic to covenant-grade trustlessness

Notable design decisions

• Lattice signed before transition — prevents MuSig2 brittleness; abort leaves the pool on a still-protected epoch
• Continuity attestation over full state table — closes the silent-majority gap; passive members are carry-forwarded and verified, not just transacting parties
• Chained commitment dependencies — commitment withholding becomes a visible liveness fault that triggers auto-exit
• Dedicated per-claimant anchors — mitigates anchor pinning griefing on shared lattice nodes
• No operator-only re-anchor — SIGHASH_ALL invalidates all pre-signed signatures on outpoint change; heartbeats must be full cooperative pulses
• Equivocation proof + bond over race-based defense — theft is not a race (no CSV on theft path); deterrent is objective fraud evidence slashable by a federation

Trust statement

PULSE converts open-membership pool custody from trusted-Operator to bonded-Operator + equivocation detection, contingent on member liveness (watchtowers) and retained exit artifacts. The exit guarantee is emulator-independent (pure pre-signed L1 transactions); Operator or emulator shutdown means freeze, never theft. Covenant-grade trustlessness is reachable only through the GSR annex; absent any fork, bonded-Operator-plus-equivocation-detection is the end state.

This is a design specification document with no code changes; compiler surface sections are marked as future work and gated.

https://claude.ai/code/session_01JcfMHSBs6QWmzEx6Xn51E2

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c18683e2-f01a-4c85-82c4-4de6e1cd3e6a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/modest-faraday-bgkkhx

---

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-45/

Built from commit 708d9d4dd34d9dc62b3e1cd4c8c4c22158a35a81 · Workflow run

[arkanaai]

🔍 Arkana Protocol Review — PULSE Specification

Reviewer: Arkana (automated, aggressive)
Verdict: Docs-only, high quality, but protocol-critical — requires human sign-off before merge.

---

Verification summary

Check	Result
Cross-references (options.md, bonds.md, arkade-primitives-spec.md)	✅ All exist
Compiler behavior claims (two-tapleaf model, N-of-N CHECKSIG chain, CSV exit, SERVER_KEY)	✅ Verified against src/compiler/mod.rs:383-815, src/parser/mod.rs:104-132
options {} grammar already supports server, exit, renew	✅ Verified in grammar.pest:20-27
Proposed recurrent flag (§11) is a natural extension	✅ Parser's match option_name has a catch-all _ => {} — new flags are ignored until implemented
No existing code references PULSE/recurrent anywhere in the codebase	✅ Clean introduction
No cross-repo consumers or coordinated PRs	✅ No breakage risk

---

Protocol analysis — what's right

1. Lattice-before-transition ordering (§7.1 steps 3→5) — The critical safety property. If T_{k+1} were signed first and lattice signing then aborted, the pool would be on a new state with no exit protection. By signing L_{k+1} first, abort leaves the pool on U_k with its existing lattice intact. Correct.

2. SIGHASH_ALL outpoint binding (§7.2) — Correctly identifies that re-anchoring changes the outpoint, voiding all pre-signed sigs. No cheap operator-only heartbeat exists. This is a real constraint well-documented here and cross-validated against the compiler's actual OP_CHECKSIG emission.

3. Exit leaf script (§6): <PULSE_KEY> OP_CHECKSIG <exit> OP_CHECKSEQUENCEVERIFY OP_DROP — Stack execution is correct: witness sig → PULSE_KEY → CHECKSIG pushes 1 → exit value → CSV checks nSequence → DROP. Matches the existing compiler pattern where N-of-N chain precedes CSV+DROP (compiler/mod.rs:745-767).

4. Chain-extension dominance (§8 row 1) — Transitions have no CSV; lattice exits wait Δ. Any holder of a newer signed T extends the chain and voids the stale lattice before it can complete. Structurally sound for the stale-state case.

5. Honest trust statement (§8 row 3, §9, §12.1) — The spec is explicit that fresh collusion beats the race (no CSV on the theft tx), and that the only defense is economic (equivocation proof + bond). No handwaving. The rejection of checkSigFromStack bond slashing due to emulator circularity (§9) is correct — an emulated opcode dies with the emulator.

6. Timelock ordering invariant (§7.4) — sweepDelay ≥ Δ + margin creating a lattice-exclusive window. The spec says the compiler should enforce this. Consistent with how the compiler already validates exit/renew relationships.

7. Attack analysis (§10) — A1–A13 are well-structured with clear severity, and each finding maps to a specific section of the spec where the defense lives. The "resolution" column is precise, not hand-wavy.

---

Findings — things to tighten

F1. §7.1 step 6 — "threshold of M_k" is underspecified (docs/recurrent-exit-pulse.md:191)

h_{k+1} is co-signed by the Operator + a threshold of M_{k+1}

When M_k is typically 1–2 parties, what does "threshold" mean? If M_k = {1 transactor}, threshold is trivially 1-of-1. If M_k = {2 transactors}, is it 1-of-2 or 2-of-2? This matters for A13 (off-chain equivocation) — a 1-of-2 threshold means a single colluding transactor can co-sign a forked h_k with the Operator. Recommend: state the threshold rule explicitly (e.g., "all of M_{k+1}" or "⌈|M_{k+1}|/2⌉ + 1").

F2. §7.1 step 3 — Dust slot members lose unilateral exit (docs/recurrent-exit-pulse.md:171-172)

Balances below the 330-sat taproot dust floor are aggregated into a single cooperative-only dust slot.

This means sub-dust members have no unilateral exit — they're stuck in a cooperative-only output. The security implication should be stated explicitly: sub-dust members degrade to full Operator trust, not just bonded-Operator trust. If this is intentional (economically trivial balances), say so. If not, it's a gap.

F3. §7.1 step 4b — O(N) verification per pulse is uncosted (docs/recurrent-exit-pulse.md:183-184)

(b) every passive slot equals the S_k carry-forward, Merkle-checked against A_{k+1}

Each transacting party verifies all N passive slots. For N = 10,000 members, that's 10K Merkle proofs per pulse. The spec costs the signing at O(N) (step 3) but doesn't cost the verification. Recommend: state the verification complexity and whether it's a practical bottleneck or if it's dominated by the O(N) lattice signing.

F4. requiredCoverage() is undefined (docs/recurrent-exit-pulse.md:142-143, docs/recurrent-exit-pulse.md:291)

The bond sizing function requiredCoverage(initialTVL) / requiredCoverage(passiveTVL) is referenced but never defined. For a design spec this is acceptable, but it's the single most important parameter for the economic security model. At minimum, the spec should state whether coverage is 1:1 (bond = passive TVL), fractional, or formula-based — the choice changes the entire threat model of §12.1 point 3.

F5. §6 — OP_DROP after CSV is present but not in current compiler (docs/recurrent-exit-pulse.md:124)

The proposed exit leaf is:

<PULSE_KEY> OP_CHECKSIG <exit> OP_CHECKSEQUENCEVERIFY OP_DROP

The current compiler (mod.rs:758-767) already emits OP_DROP after OP_CHECKSEQUENCEVERIFY. Consistent. Just confirming this is intentional and not a copy error — the DROP is needed because CSV doesn't consume its argument.

F6. Cross-reference to options.md is technically misleading (docs/recurrent-exit-pulse.md:11)

Cross-references: options.md (two-tapleaf model, exit/renew options)

options.md documents CoveredCall/CashSecuredPut (financial options), not the compiler's options {} block. The cross-reference to the two-tapleaf model discussion within that doc (§Cooperative vs exit paths) is valid, but a reader following the link expecting compiler grammar docs will be confused. Consider adding a parenthetical: "two-tapleaf model as demonstrated in financial options" or cross-referencing the grammar directly.

---

Non-findings — things I checked and found correct

• §7.3 unilateral exit walk: The 4-step sequence (chain tip → lattice root after Δ → branch path with CPFP → sweep after slot CSV) is consistent with how the compiler's exit variants work.
• §7.2 heartbeat: No operator-only re-anchor — correct given SIGHASH_ALL. The spec doesn't claim any way around this, which is honest.
• §9 forced-nonce-reuse rejection: Correct — plain CHECKSIG with a fresh nonce defeats key-leak punishment. Script can't pin the nonce.
• §11 proposed grammar: recurrent = true; as a new option_setting — the parser's catch-all _ => {} means this won't break anything until implemented. Future work is properly gated.
• A9 sweep-races-exit: The timelock ordering invariant is the correct fix and is proposed as a compiler-enforced check.

---

Verdict

This is an exceptionally well-structured protocol specification. The trust model is honest, the attack analysis is thorough, and the claims about the existing compiler are verified accurate. The "lattice before transition" ordering, the honest acknowledgment of the theft-race asymmetry, and the rejection of circular bond slashing show careful adversarial thinking.

However, this is protocol-critical. It specifies exit paths, VTXO lifecycle, and the trust model for pool custody. Findings F1 (threshold ambiguity) and F2 (dust slot trust degradation) should be addressed before this becomes the canonical reference for implementation. F4 (undefined requiredCoverage) is the biggest open question for economic security.

⚠️ Requesting human review per protocol-critical policy. Even though this is docs-only with no code changes, the spec will directly guide the implementation of exit leaf compilation, lattice construction, and bond enforcement — all of which are money-handling code paths. A human must sign off.

---

🤖 Reviewed by Arkana — #45

[arkanaai]

🔍 Arkana Protocol Review — PULSE commit 3 (fa48fb7)

Reviewer: Arkana (automated, aggressive)
Scope: New commit only — §7.1a, §8 expansion, §8a recourse, A14/A15, §12.1.6, msg.sender cleanup.

---

What's right in the new material

1. §7.1a conservation predicate is the correct fix for A14. The buggy-honest gap (A_k matches the buggy lattice → no lie → no slash) was a real hole. Making Σ(leaf values) + dust + Σ(fees) == value(U_k) a public, anyone-can-check finality gate is the right call. The cascading fallback ("auto-exit on k−1, the last epoch that passed both checks") handles multi-epoch corruption correctly.

2. §8a recourse ladder is honest and correctly ordered. The sharp statement that recourse terminates at bonded compensation for passive members under active collusion is the right thing to put in a spec. The race analysis ("Why the detect-before-consumed race favors the thief") is structurally correct — the Δ CSV on the exit leaf vs no CSV on the consuming transition is an unavoidable asymmetry, and the spec doesn't pretend otherwise.

3. A14 finding and resolution are well-structured. Severity HIGH is correct — silent unbacked loss with no slashable evidence is worse than a liveness halt.

4. A15 and §12.1.6 — sub-dust named honestly as permanent. Correct. Bounded ≤ 330 sat, attested for compensation provability. No hand-waving.

5. Dispute window framing (§8 expansion) is sound. Using the Δ window for both contest (chain-extension) and dispute (bond earmark + client refusal) is a clean reuse. The halting mechanism (honest co-signers refuse disputed tips) is the correct no-covenant analogue.

6. msg.sender → transacting party cleanup. Good hygiene.

---

Findings on the new material

F7. §12.1 item 6 — broken cross-reference: "§7.1.3" does not exist (docs/recurrent-exit-pulse.md:501)

aggregated into a cooperative-only dust slot (§7.1.3)

There is no §7.1.3. The dust slot is defined in §7.1 step 3 (the lattice-first step). The correct reference is "§7.1 step 3" or just the line about the 330-sat floor. Minor but this is a spec that will guide implementation — broken cross-refs cause misreads.

F8. §7.1a conservation formula — "Σ(path fees)" needs a definition (docs/recurrent-exit-pulse.md:220)

Σ(leaf values of L_k) + dust slot + Σ(path fees) == value(U_k)

"Path fees" is used only here and never defined. For a reviewer or implementer: is this the sum of mining fees across all internal-node transactions in the lattice tree? If so, state it explicitly — e.g., "the cumulative mining fees of every transaction in the lattice tree, from root to leaves." The checker needs the full tree structure to compute this, which is non-obvious from "recomputed from the published S_k, root(L_k), and the on-chain value(U_k)." root(L_k) alone doesn't give you internal-node fees without the full tree.

F9. §8 dispute window — earmark trigger mechanism is underspecified (docs/recurrent-exit-pulse.md:290-293)

a standardized, machine-checkable evidence bundle (A_j plus the contradicting L_k or forked h_k) does two things during Δ: it makes the federation earmark the bond

Who submits the evidence bundle to the federation? Through what channel? Is there a time bound on the federation's response? If the federation takes longer than Δ to process the earmark, the dispute window expires and the attacker's transition confirms. This is the critical path for the dispute mechanism — the spec should at minimum state whether earmarking must complete within Δ or whether it has its own timeline.

F10. §8 artifact retention relaxation — slightly over-optimistic for the fraud-proof case (docs/recurrent-exit-pulse.md:285-287)

Old text: "A member that discards these has no fraud proof."
New text: "the data only needs to exist somewhere, not necessarily with the victim."

This is correct for the exit broadcast function (anyone with the lattice branch can broadcast on the victim's behalf). But for the fraud proof function, someone still needs to hold the conflicting artifacts (the victim's L_k signature vs the theft tx). If the relay mesh and all archival watchtowers lose the data — which the old text warned against — the fraud proof is gone. The new text is technically correct ("any surviving copy") but softens the warning. Consider keeping the original warning and adding the mesh/archival note as a mitigation, not a replacement.

F11. §8a "Stale-but-correct" row — missing epoch-distance nuance (docs/recurrent-exit-pulse.md:319)

Stale-but-correct | your L_k is correct but U_k was already consumed by a newer (bad) transition | COMPENSATION-ONLY in the realistic case

This tags "stale-but-correct" as COMPENSATION-ONLY but doesn't distinguish between stale-by-1-epoch (where the consuming T_{k+1} might not yet be confirmed, giving a brief race window) vs stale-by-many-epochs (where multiple transitions have confirmed and the race is unwinnable). The "realistic case" caveat covers it loosely, but an implementer deciding whether to attempt a last-good-epoch exit needs to know: the race window is roughly Δ - (blocks since U_k confirmed), which is zero for any stale epoch older than Δ blocks. Worth a one-line clarification.

---

Previous findings status

My initial review (commit 2) raised F1–F6. Checking which the new commit addresses:

• F1 (threshold ambiguity in §7.1 step 6) — Not addressed in this commit. Still open.
• F2 (dust slot trust degradation) — ✅ Addressed. §8a sub-dust row + §12.1 item 6 + A15 now name this explicitly as a permanent, bounded gap with attestation-based compensation provability. Exactly what was requested.
• F3 (O(N) verification uncosted) — Not addressed. Still open (minor).
• F4 (requiredCoverage() undefined) — Not addressed. Still the biggest open question for economic security.
• F5 (OP_DROP confirmation) — Was a confirmation, not a finding. No action needed.
• F6 (options.md cross-reference) — Not addressed. Still a minor readability issue.

---

Verdict on new material

The third commit directly addresses my F2 finding and adds substantial, correct protocol analysis. §7.1a is an important safety rule. §8a is the most honest recourse analysis I've seen in an L2 spec — the "Bottom line" statement is exactly what users and implementers need to read. The new findings (A14, A15) are well-motivated by the recourse analysis.

Open items from both reviews: F1 (threshold), F4 (requiredCoverage), F7 (broken xref), F8 (path fees), F9 (earmark trigger). F1 and F4 are the ones that matter for implementation; F7 is a quick fix.

⚠️ Protocol-critical — human review still required. The recourse section directly specifies what happens when users lose money. Getting the failure-mode tags wrong would give implementers the wrong mental model for error handling.

🤖 Reviewed by Arkana — #45 (incremental, commit 3)

[arkanaai]

🔍 Arkana Protocol Review — PULSE commit 4 (3b6c2d8)

Reviewer: Arkana (automated, aggressive)
Scope: New material only — §13 (security model + dialectical review), rewritten trust statement, §8a back-reference tweak.

---

What's right in the new material

1. §13.1 is the most important section in the spec. The mechanism/amount split is the fundamental insight, and naming it explicitly with a table is exactly what reviewers and implementers need. The comparison to statechains, coinpools, and Ark is precise — the key distinction (victim is not a signer of the transition that can rob them, carry-forward check is policy-enforced not incentive-compatible) is the correct game-theoretic analysis. This section alone justifies the commit.

2. §13.2 trilemma is correctly stated and the corner choice is honest. (a) + (b) → relax (c). The three alternatives are enumerated correctly. The statement "the trilemma is the design" is the right framing for a spec — it shuts down the "just fix it" reflex.

3. §13.3 dialectical table is clean. Thesis/antithesis/synthesis on the three structural tensions. The third row — "a cryptographically-enforced mechanism around an economically-enforced amount — a hybrid, not trustless" — is the one-liner the whole document has been building toward. Good.

4. §13.4 halt analysis is complete. Three vectors, correctly bounded. The machine-checkable caveat on dispute-triggered halts (item 3) is important — "cry wolf" as a DoS is a real concern and the spec names it.

5. §13.5 operator centrality is stated without flinching. "No valid exit lattice can be produced without [the Operator]" is the right thing to write. The federation recommendation correctly states the honest ceiling: "widens the trusted set but does not convert the amount model into a clean 1-of-N."

6. §13.6 feasibility section grounds the spec in deployable Bitcoin. clArk reference, P2A/TRUC/ephemeral anchors, SIGHASH_ALL cascade — all real, all merged. The parenthetical clarifying "lattice" vs lattice cryptography is a nice touch for readers coming from a different field.

7. Rewritten trust statement leads with the split. Much stronger than the old version. "Trustless-mechanism / bonded-amount" as the tagline is accurate and will travel well.

---

Findings on the new material

F12. §13.1 — "as small as two" undersells the worst case (docs/recurrent-exit-pulse.md:567)

the set … can be as small as two

This is {Operator, 1 transacting party}. But the spec already established (A2, §7.1 step 4b commentary) that a 1-party pulse with a colluding Operator is the degenerate case. In that scenario, the "set whose honesty protects a passive member" is {Operator, that one party} — and if both collude, the set has zero honest members. The table should say "as small as two, and if both collude the honest count is zero" to close the ambiguity on what "as small as two" means for the passive member. The paragraph below the table explains this correctly, but the table cell itself could mislead a skimmer.

F13. §13.4 item 3 — "machine-checkable" evidence format is never specified (docs/recurrent-exit-pulse.md:621-622)

conforming clients must halt only on machine-checkable evidence

This is the right rule but it needs a forward reference to where the evidence format will be defined. Without a concrete format, two independent implementations will disagree on what constitutes valid dispute evidence, creating a consensus split at the social layer — some clients halt, others don't, the pool fractures. At minimum, add a placeholder: "the machine-checkable evidence format is defined in [§X / future work / the compiler surface]." If it's genuinely undefined, flag it as an open item in §11 (compiler surface).

F14. §13.5 — federation threshold k is introduced but never bounded (docs/recurrent-exit-pulse.md:633-636)

make "the Operator" a k-of-n federation … raises the theft-collusion threshold from "Operator + M_k" to "k operators + M_k"

What are the constraints on k and n? A 1-of-3 federation is worse than a single honest Operator (any one compromised node enables collusion). A 3-of-3 federation is maximally secure but fragile to liveness failures. The spec recommends this as "the baseline operator construction" but gives implementers no guidance on threshold selection. At minimum state: "k must be chosen such that compromising k nodes is harder than compromising 1 Operator, while n − k + 1 honest nodes suffice for liveness" — or defer to §9/bonds.md with an explicit cross-reference.

F15. §13.6 — "P2A standard since Bitcoin Core 28.0" needs version pinning in the spec (docs/recurrent-exit-pulse.md:653-654)

dedicated per-leaf anchors via P2A (standard since Bitcoin Core 28.0)

This is correct today (Core 28.0 shipped April 2025), but the spec should note that nodes running <28.0 will not relay P2A transactions. For a protocol spec that will guide implementation, add: "Implementations MUST require connected peers to support P2A relay (Core ≥28.0 or equivalent); lattice transactions broadcast to pre-28.0 nodes will not propagate." This matters for exit reliability — a lattice broadcast that doesn't propagate is a failed exit.

F7 (carried). §12.1 item 6 / §13.6 — "§7.1.3" still does not exist (docs/recurrent-exit-pulse.md:503, 654)

aggregated into a cooperative-only dust slot (§7.1.3)
§7.1.3's "dedicated anchors + TRUC" is real

Flagged in my commit-3 review. Still broken. Now referenced from two locations (§12.1 and the new §13.6). The dust slot is in §7.1 step 3; the anchors are in the bullet under step 3. The correct reference is "§7.1 step 3" in both places.

---

Previous findings status (cumulative)

Finding	Status	Notes
F1 (threshold ambiguity §7.1 step 6)	⚠️ Open	"a threshold of M_{k+1}" — still undefined. Not addressed in commit 4.
F2 (dust slot trust degradation)	✅ Closed	Addressed in commit 3.
F3 (O(N) verification uncosted)	ℹ️ Open (minor)	Not addressed. Low priority.
F4 (requiredCoverage() undefined)	⚠️ Open	Still the biggest implementation blocker for economic security. Not addressed.
F5 (OP_DROP confirmation)	✅ N/A	Was a question, not a finding.
F6 (options.md cross-reference)	ℹ️ Open (minor)	Not addressed.
F7 (§7.1.3 broken xref)	⚠️ Open, worsened	Now broken in two places (§12.1 + new §13.6).
F8 (path fees undefined)	⚠️ Open	Not addressed.
F9 (earmark trigger underspecified)	⚠️ Open	Not addressed.
F10 (artifact retention softened)	ℹ️ Open (minor)	Not addressed.
F11 (stale-but-correct epoch distance)	ℹ️ Open (minor)	Not addressed.
F12 (NEW — "as small as two" ambiguity)	⚠️ New	See above.
F13 (NEW — machine-checkable format undefined)	⚠️ New	See above.
F14 (NEW — federation k unbound)	⚠️ New	See above.
F15 (NEW — P2A version pinning)	ℹ️ New (minor)	See above.

---

Verdict on commit 4

§13 is the intellectual core of the spec. The trilemma framing, the mechanism/amount split, and the honest operator-centrality statement are all correct and well-argued. The rewritten trust statement is a significant improvement — it's now impossible to misread PULSE as claiming trustless amount-safety.

Remaining blockers for implementation readiness (in priority order):

1. F4 — requiredCoverage() is the bond sizing function. Without it, no one can implement §9. This is the single most important open item.
2. F1 — The threshold in §7.1 step 6 determines commit-header security. "A threshold" is not a spec.
3. F13 — Machine-checkable evidence format is the linchpin of §13.4 item 3 and §8a's dispute mechanism. Without a format, the social layer has no consensus.
4. F14 — Federation threshold guidance. The spec recommends this as baseline but gives no constraints.
5. F7 — Broken cross-refs. Quick fix, two locations.

The new material has no correctness errors. All findings are specification-completeness issues, not protocol bugs.

⚠️ Protocol-critical — human review required. §13's security model directly defines what users can and cannot trust. The trilemma framing will be cited by downstream documentation, marketing, and user-facing materials. Getting the precise claims wrong has downstream consequences beyond code.

🤖 Reviewed by Arkana — #45 (incremental, commit 4)

[arkanaai]

🔍 Arkana Protocol Review — PULSE commit 5 (69fd826)

Reviewer: Arkana (automated, aggressive)
Scope: Incremental — only changes since commit 4 (3b6c2d8).

---

Commit 5 addresses prior review feedback: threshold parameterization, bond sizing clarification, xref fixes, trust-table sharpening, dispute evidence admissibility, federation guidance, and a P2A relay caveat. All improvements. Two items below.

1. Federation threshold math is ambiguous — line 655

n − k + 1 honest-and-live operators still suffice to advance and attest

In a k-of-n threshold scheme, you need k signers to advance. The tolerance for offline nodes is n − k. The phrase "n − k + 1 suffice to advance" is only true when n − k + 1 ≥ k (i.e. n ≥ 2k − 1).

I think the intended reading is: "if up to k − 1 nodes are compromised (safety still holds), the remaining n − k + 1 honest nodes must still meet the signing threshold k" — which is a design constraint (n ≥ 2k − 1), not a general truth.

Suggested rewrite (or something equivalent):

pick k and n so that compromising k independently-run operators is strictly harder than compromising one (k ≥ 2), and ensure n ≥ 2k − 1 so that even after k − 1 compromises (safety margin intact), the remaining n − k + 1 honest operators still meet the k-of-n signing threshold needed to advance.

This makes the constraint explicit rather than leaving the reader to infer it.

2. Dispute evidence wire format — open item gap (minor)

Line 632–634 correctly flags the dispute-evidence wire serialization as an open SDK/ABI item for §11. But §11's ABI field list (lines 463–467) doesn't explicitly include it — it lists continuity-attestation format and bond reference but not dispute-evidence bundle format. Worth adding a bullet to §11 so implementers don't miss it.

---

Verdict

Both items are clarification-level, not correctness bugs. The substantive changes in this commit (per-epoch bond floor, t parameterization, P2A relay caveat, collusion-count explainer in the trust table) are all correct and strengthen the spec. Approving — these can be addressed in a follow-up or before merge at the author's discretion.

🤖 Reviewed by Arkana — #45 (incremental, commit 5)

[arkanaai]

🔍 Arkana Protocol Review — PULSE commit 5 (69fd826)

Reviewer: Arkana (automated, aggressive)
Scope: Incremental — only changes since commit 4 (3b6c2d8).

---

Commit 5 addresses prior review feedback: threshold parameterization, bond sizing clarification, xref fixes, trust-table sharpening, dispute evidence admissibility, federation guidance, and a P2A relay caveat. All improvements. Two items below.

1. Federation threshold math is ambiguous — line 655

n − k + 1 honest-and-live operators still suffice to advance and attest

In a k-of-n threshold scheme, you need k signers to advance. The tolerance for offline nodes is n − k. The phrase "n − k + 1 suffice to advance" is only true when n − k + 1 ≥ k (i.e. n ≥ 2k − 1).

I think the intended reading is: "if up to k − 1 nodes are compromised (safety still holds), the remaining n − k + 1 honest nodes must still meet the signing threshold k" — which is a design constraint (n ≥ 2k − 1), not a general truth.

Suggested rewrite (or something equivalent):

pick k and n so that compromising k independently-run operators is strictly harder than compromising one (k ≥ 2), and ensure n ≥ 2k − 1 so that even after k − 1 compromises (safety margin intact), the remaining n − k + 1 honest operators still meet the k-of-n signing threshold needed to advance.

This makes the constraint explicit rather than leaving the reader to infer it.

2. Dispute evidence wire format — open item gap (minor)

Line 632–634 correctly flags the dispute-evidence wire serialization as an open SDK/ABI item for §11. But §11's ABI field list (lines 463–467) doesn't explicitly include it — it lists continuity-attestation format and bond reference but not dispute-evidence bundle format. Worth adding a bullet to §11 so implementers don't miss it.

---

Verdict

Both items are clarification-level, not correctness bugs. The substantive changes in this commit (per-epoch bond floor, t parameterization, P2A relay caveat, collusion-count explainer in the trust table) are all correct and strengthen the spec. Approving — these can be addressed in a follow-up or before merge at the author's discretion.

🤖 Reviewed by Arkana — #45 (incremental, commit 5)

[arkanaai]

🔍 Arkana Protocol Review — PULSE commit 6 (c5468ec)

Scope: Doc-only delta since commit 5 (69fd826). Two changes, both addressing my prior review.

Fixes verified

Finding	Fix	Verdict
Federation threshold constraint was unstated	Added n ≥ 2k − 1 — after k − 1 compromises, remaining n − k + 1 ≥ k honest operators still meet the k-of-n signing threshold. Math checks out.	✅
Dispute-evidence bundle format missing from §11 ABI field list	Now listed in the recurrentExit field set with rationale (prevents client disagreement on valid halt triggers) and §13.4 back-reference.	✅

No new issues found

No protocol claims changed. No code. Both fixes are precise and correctly scoped.

---

Approval maintained. Still protocol-critical (VTXO exit paths, signing ceremonies, forfeit/bond mechanics) — human sign-off required before merge.

[arkanaai]

🔍 Arkana Protocol Review — PULSE commit 7 (448cc39)

Scope: Doc-only delta since commit 6 (c5468ec). Adds section 1.2, a plain-language walkthrough with no math.

Protocol accuracy check

Cross-referenced every claim in the new walkthrough against the technical spec sections:

Walkthrough claim	Spec section	Verdict
Operator = clerk, can't steal	§3 exit leaf, §5 trust model	✅ Correct
Fresh exit tickets each pulse	§5 lattice signing ceremony	✅ Correct
Old tickets invalidated via nonce destruction	§5 ephemeral keys, MuSig2	⚠️ See below
Public headcount = continuity attestation	§5.2 A_{k+1} over full state table	✅ Correct
Bond slashed on equivocation	§9 bond + fraud proof	✅ Correct
Watchdog = watchtower auto-exit	§7 watchtower liveness	✅ Correct
"The honest catch" — passive amounts not self-signed	§5 trust model, §8 threat classes	✅ Correct and well-stated
Recurrent = heartbeat renewal	§6 heartbeat lifecycle	✅ Correct

One nit (non-blocking)

docs/recurrent-exit-pulse.md:63-66 — "Old tickets can't be reused … So nobody — not even the clerk — can quietly write a second, different set for the same moment."

This slightly oversells the cryptographic guarantee. The spec's own §8 threat class 3 ("fresh colluding theft") shows that if the Operator colludes with all transacting parties who held the epoch nonces, a second conflicting signature is constructible — the defense is economic (equivocation proof → bond slash), not cryptographic impossibility. The "honest catch" section at the end does correct this impression, so the walkthrough is balanced overall, but this specific bullet could say "it becomes detectable and punishable" rather than flatly "nobody can."

Not requesting changes — the document's own trust statement and "honest catch" paragraph make the correct nuance clear. This is good work.

🤖 Reviewed by Arkana — #45 (incremental, commit 7)

[arkanaai]

🔍 Arkana Protocol Review — PULSE commit 7 (448cc39)

Scope: Doc-only delta since commit 6 (c5468ec). Adds section 1.2, a plain-language walkthrough with no math.

Protocol accuracy check

Cross-referenced every claim in the new walkthrough against the technical spec sections:

Walkthrough claim	Spec section	Verdict
Operator = clerk, can't steal	§3 exit leaf, §5 trust model	✅ Correct
Fresh exit tickets each pulse	§5 lattice signing ceremony	✅ Correct
Old tickets invalidated via nonce destruction	§5 ephemeral keys, MuSig2	⚠️ See below
Public headcount = continuity attestation	§5.2 A_{k+1} over full state table	✅ Correct
Bond slashed on equivocation	§9 bond + fraud proof	✅ Correct
Watchdog = watchtower auto-exit	§7 watchtower liveness	✅ Correct
The honest catch — passive amounts not self-signed	§5 trust model, §8 threat classes	✅ Correct and well-stated
Recurrent = heartbeat renewal	§6 heartbeat lifecycle	✅ Correct

One nit (non-blocking)

docs/recurrent-exit-pulse.md:63-66 — "Old tickets can't be reused … So nobody — not even the clerk — can quietly write a second, different set for the same moment."

This slightly oversells the cryptographic guarantee. The spec's own §8 threat class 3 ("fresh colluding theft") shows that if the Operator colludes with all transacting parties who held the epoch nonces, a second conflicting signature is constructible — the defense is economic (equivocation proof → bond slash), not cryptographic impossibility. The "honest catch" section at the end does correct this impression, so the walkthrough is balanced overall, but this specific bullet could say "it becomes detectable and punishable" rather than flatly "nobody can."

Not requesting changes — the document's own trust statement and "honest catch" paragraph make the correct nuance clear. This is good work.

🤖 Reviewed by Arkana — #45 (incremental, commit 7)

[arkanaai]

🔍 Arkana Review — commit 512d059 (incremental)

Scope: One commit since last approval. Docs-only.

Changes reviewed

1. Bond slashing mechanics paragraph (lines ~452–467) — New substantive content explaining why slashing is not pure Bitcoin Script. Technically accurate:

   • Correct that OP_CHECKSIGFROMSTACK is absent from Bitcoin consensus.
   • Correct that Script cannot verify a signature against an arbitrary message on the stack.
   • Correct that Lightning-style nonce-reuse key-leak requires pinning the nonce (a covenant).
   • Trust assumption (≥1 honest referee in k-of-n) clearly stated and correctly scoped.
   • Future opcode path (OP_CHECKSIGFROMSTACK, OP_CAT-based OTS) correctly referenced to §12.2.

2. Walkthrough rewrite (lines ~62–67) — "Old tickets can't be reused" → "Old tickets can't be quietly rewritten." More honest — now acknowledges the clerk+all-participants collusion edge case while explaining the bond backstop. Good.

3. Branding cleanup — Ark → Arkade, clArk removed, "Ark-grade" → "the strongest tier", "once-per-round" → "once-per-batch". All correct, no semantic drift.

Verdict

Clean incremental improvement. No protocol correctness issues. Still docs-only, still protocol-critical — human sign-off required before merge.

✅ Approved (automated). Waiting on human reviewer.

[arkanaai]

🔍 Arkana Review — commit 512d059 (incremental)

Scope: One commit since last approval. Docs-only.

Changes reviewed

1. Bond slashing mechanics paragraph (lines ~452–467) — New substantive content explaining why slashing is not pure Bitcoin Script. Technically accurate:

   • Correct that OP_CHECKSIGFROMSTACK is absent from Bitcoin consensus.
   • Correct that Script cannot verify a signature against an arbitrary message on the stack.
   • Correct that Lightning-style nonce-reuse key-leak requires pinning the nonce (a covenant).
   • Trust assumption (≥1 honest referee in k-of-n) clearly stated and correctly scoped.
   • Future opcode path (OP_CHECKSIGFROMSTACK, OP_CAT-based OTS) correctly referenced to §12.2.

2. Walkthrough rewrite (lines ~62–67) — "Old tickets can't be reused" → "Old tickets can't be quietly rewritten." More honest — now acknowledges the clerk+all-participants collusion edge case while explaining the bond backstop. Good.

3. Branding cleanup — Ark → Arkade, clArk removed, "Ark-grade" → "the strongest tier", "once-per-round" → "once-per-batch". All correct, no semantic drift.

Verdict

Clean incremental improvement. No protocol correctness issues. Still docs-only, still protocol-critical — human sign-off required before merge.

✅ Approved (automated). Waiting on human reviewer.

[arkanaai]

🔍 Arkana Review — commit 3b758f9 (incremental)

Reviewer: Arkana (automated, aggressive)
Scope: Single new commit 3b758f9 — adds threshold-MPC realization paragraph to §13.5.

Verdict: ✅ APPROVE (doc-only, no code changes)

What changed: One 25-line paragraph appended to §13.5, describing how the k-of-n federated operator is best instantiated as a threshold-MPC signing network (2PC-MPC named as concrete example).

Checked:

1. Cross-references valid. Claims reference A2 (silent-majority gap), A8 (key resurrection), §9 (bond/referee federation), §13.2 (trilemma) — all exist and are consistent with the new text.

2. Critical safety claim verified. The paragraph asserts "the MPC sits on the cooperative path only — the exit must stay pre-signed and MPC-independent." This is consistent with the exit mechanism (§6: <PULSE_KEY> OP_CHECKSIG <exit> OP_CSV, lattice is fully pre-signed per §5 table). The new text does not introduce any MPC dependency into the unilateral exit path. ✅

3. Honest ceiling correctly stated. The paragraph explicitly says threshold-MPC does not make the victim a signer, does not escape the §13.2 trilemma, and merely moves trust from "one Operator" to "MPC threshold" — quantitatively stronger but still committee trust. Consistent with §13.5's existing ceiling analysis. ✅

4. External dependency flagged. The paragraph correctly warns that threshold-MPC imports liveness, security, and economic assumptions from the MPC network — an honest caveat. ✅

5. No section numbering breakage. §13.6 follows correctly after the insertion.

No issues found. Clean incremental addition with proper hedging and accurate cross-references.

🤖 Reviewed by Arkana — #45 (incremental, commit 3b758f9)

[arkanaai]

🔍 Arkana Review — commit a5b3897 (incremental)

Reviewer: Arkana (automated, aggressive)

Scope of change: Two additions since 3b758f9:

1. Table of contents (lines 16–53) — all 35 anchor links verified against actual section headers. Clean, no broken links.

2. MPC Sybil-resistance caveat (lines 803–817, §13.5) — states that threshold-MPC benefit depends on genuine node independence, which is an unprovable real-world property (same class as key deletion A8 and federation non-collusion §9). Correctly identifies the degradation path: fake threshold collapses to single-Operator-collusion case (§8 row 3), but no worse — exit stays MPC-independent, bonded-amount model already assumes collusion. Recommends Nakamoto-coefficient floor gating for the "MPC-secured" label.

Verdict: Sound analysis. The requiredCoverage cross-reference (§12.1 item 3) is valid. The "never beneath the existing floor" claim is consistent with the exit-mechanism / exit-amount split established in §13.1 and the trilemma in §13.2. No protocol-critical concerns.

✅ Approved.

🤖 Reviewed by Arkana — #45 (incremental, commit a5b3897)

[arkanaai]

🔍 Arkana Review — commit a5b3897 (incremental)

Reviewer: Arkana (automated, aggressive)

Scope of change: Two additions since 3b758f9:

1. Table of contents (lines 16–53) — all 35 anchor links verified against actual section headers. Clean, no broken links.

2. MPC Sybil-resistance caveat (lines 803–817, §13.5) — states that threshold-MPC benefit depends on genuine node independence, which is an unprovable real-world property (same class as key deletion A8 and federation non-collusion §9). Correctly identifies the degradation path: fake threshold collapses to single-Operator-collusion case (§8 row 3), but no worse — exit stays MPC-independent, bonded-amount model already assumes collusion. Recommends Nakamoto-coefficient floor gating for the "MPC-secured" label.

Verdict: Sound analysis. The requiredCoverage cross-reference (§12.1 item 3) is valid. The "never beneath the existing floor" claim is consistent with the exit-mechanism / exit-amount split established in §13.1 and the trilemma in §13.2. No protocol-critical concerns.

✅ Approved.

🤖 Reviewed by Arkana — #45 (incremental, commit a5b3897)