Security Analysis
This page sets out the threat model for claims in the proposed bidirectional MAST engine: the attacks against inverted claims, what defeats each one, and the risks the design deliberately leaves to other layers. Ticket authentication is only as convincing as this analysis, so reviewers who find a gap are encouraged to raise it as a design issue before implementation begins, when fixing it costs nothing.
Frontrunning
In the frontrunning scenario, an honest payer builds a qualifying action and moves to claim, an observer copies the visible claim inputs, and the observer submits first with itself as the sender. With a first-claimer-wins payout, the copy would win unless the design prevents it, and with public mempools watched continuously by bots, the scenario is realistic.
Three layers answer it in sequence. Credential secrecy means observers don’t know the ticket before submission, because it travels through memo carriage and private handoff. Private relay keeps the submission itself out of the public mempool and delivers it directly. The nullifier set is the final backstop, defeating reuse against the same action once the first confirmation spends the note.
Each layer is necessary and none is sufficient on its own: secrecy without private relay leaks at the last step, relay without nullifier marking allows same-action replays, and nullifier marking without secrecy invites a race for the first confirmation. The tooling enables private relay by default, so a payer following the defaults gets all three layers without configuring anything; a payer who overrides them and submits publicly accepts the frontrunning risk, which the documentation states plainly.
Replay across actions
A revealed ticket stays cryptographically valid after its first use, which raises the possibility of combining an observed ticket with a new qualifying action. This attack is economically very different from replaying against the same action: the attacker must construct and get mined a genuine qualifying Zcash payment, paying real value plus fees, so it costs nearly as much as honest participation and adds cryptographic risk.
Single-use leaves close even this narrow opening by recording spent tickets keyed by s, so the first valid submission consumes the ticket whatever the action. Multi-fill leaves deliberately leave it open, because the lock’s author intends repeated settlement and per-action nullifier marking already prevents paying twice for one note. The per-leaf flag lets each lock pay only for the protection it needs.
Malleability
Classic signature malleability turns a valid signature into a different valid signature over the same message, typically by negating s and flipping the recovery identifier. The design neutralizes this structurally rather than by normalizing signatures: the components carried in the memo can’t be altered without breaking byte equality with the committed region, so a malleated variant fails before the recovery call runs, leaving no point at which an attacker could substitute one.
Boundary checks complete the picture without overreaching. Recovery identifiers outside the accepted pair revert immediately, and malformed encodings revert through the precompile’s zero output. These checks reject garbage rather than enforcing a canonical signature form, so honest creator output always passes unmodified, a property that designs relying on heavy normalization can’t guarantee.
Key compromise and rotation
If a script private key is compromised, whoever holds the copy can mint tickets. The damage is limited by the credential’s scope: forged tickets can authorize claims only against the lock whose leaf commits that key, and only for actions that satisfy that leaf’s constraints. No other lock, leaf or unrelated funds are affected, which keeps a single compromise from becoming a systemic event.
Rotating after a suspected compromise requires a new lock, because committed leaf contents are immutable. There is deliberately no way to upgrade a live leaf, since mutable terms would undermine every guarantee the Merkle binding provides. Operators of long-lived arrangements should therefore rotate through expiring locks with overlapping validity rather than rely on any single indefinite credential; rotation policy belongs in deployment runbooks, not consensus code.
Spam
Because anyone can submit a claim, anyone can submit invalid ones: malformed claims, claims against unmined actions, or claims with forged tickets. Each costs the attacker gas and reverts without touching escrow, nullifiers or ticket records. The asymmetry favors the defender: rejecting an invalid claim costs the network one reverted execution, while producing it costs the attacker real fees, and there is no way to turn the attacker’s spending into losses for anyone else. The only shared cost is block space, which is bounded by gas pricing as for any permissionless entry point.
Dependence on finality
Inverted claims prove inclusion against anchored history, and the anchor must be finalized rather than fresh: an action confirmed in a tip block that is later reorganized away would otherwise leave a paid claim backed by vanished history. The claim path therefore accepts inclusion only against finalized roots, using the same rollups as the existing direction, and a fresh tip never qualifies however many confirmations it has. This dependence is inherited, not introduced: every settlement path already requires finalized inclusion, so reviewers assessing reorganization risk can apply Chain Finality unchanged.
Cryptographic assumptions
The analysis rests on standard assumptions, stated explicitly: ECDSA signatures can’t be forged without the private key (by the hardness of the elliptic-curve discrete logarithm problem); the ecrecover precompile implements verification correctly; Keccak-256 Merkle proofs bind leaves as analyzed; and the recovery identifier behaves as pseudorandom output over committed bytes, needing no further structure for the checks performed. Each matches common practice for bridge verification, and no step depends on a novel conjecture. A break in any of them would compromise far more than this design.
Outside the threat model
Two risks are deliberately left to other layers. A double-spend of a claimed action on the Zcash side after payout is a layer-one reorganization, handled by the requirement for finalized anchors rather than by claim logic. Theft of credentials from compromised endpoints is an operational-security matter, mitigated by custody practice and rotation schedules, since consensus can’t distinguish legitimate from stolen use of identical bytes. Stating these exclusions is part of the analysis: a threat model that claimed to cover everything would invite the suspicion that it had examined nothing.