Drops Protocol documentation

    Interactive · client-side only

    Pact outcome verifier

    A recorded outcome claims that a Pact moved from one state to the next. This tool checks that the claim holds together: same Pact, sequence advanced by one, roots that line up, and a successor that commits to this exact transition and no other.

    A dark studio scene: a magnifying glass over a glowing droplet outline, a stack of illuminated ledger blocks with a bronze Bitcoin disc on top, a chain of small blocks, and a shield bearing a checkmark.
    Checking an outcome is arithmetic on records, not a judgement about people.
    Your input stays in your browser

    One static JavaScript file, no network calls, no storage. Nothing you paste is transmitted, logged or cached anywhere, including on the server hosting this page. Read the source. It works offline once the page is saved.

    The state the Pact was in before this outcome.

    The state the outcome claims the Pact reached.

    The stated terms of the move: which Pact, from which outpoint, from which state to which state, under which policy.

    The OP_RETURN output that marks the transition on chain. Supply it to also check rule P-9.

    This tool needs JavaScript. The rules it applies are written out as P-1 through P-9 on the Drop Pacts page, and the same worked cases appear with expected results under Pact test vectors. Nothing here is available only through the tool.

    Worked outcomes

    Both samples are real records built with the same encoding the reference implementation uses. The commitment is recomputed in your browser from the preimage you load, so the pass and the failure are both genuine.

    A consistent outcome

    A Pact moving from sequence 7 to sequence 8, with a matching DPC1 anchor. Every check this tool can perform passes.

    A tampered outcome

    The same records with one byte changed in the successor cell descriptor. Rule P-7 fails while P-9 still passes, so the tool points at the altered record rather than at the stated terms.

    Scope, stated plainly

    This tool runs five of the nine outcome rules. It says so in its own output, every time, rather than presenting a partial check as a complete one.

    Coverage against the outcome rules
    RuleChecked hereWhy
    P-1 Pact ids agreeyesAll three records carry it.
    P-2 Sequence advances by oneyesBoth descriptors carry a sequence.
    P-3 Roots line upyesState and policy roots are in the records.
    P-4 Ruleset result equals the next state rootnoNeeds the deterministic CBOR proof pack, which is off-chain material rather than a record.
    P-5 OP_DROP effect hash matches its payloadno
    P-6 Proof pack payload hash matchesno
    P-7 Successor commits to this transitionyesRecomputed from the preimage with a BIP 340 tagged hash.
    P-8 Successor proves its Taproot commitmentnoNeeds the control block, the successor output script, and secp256k1 point arithmetic.
    P-9 DPC1 anchor carries the same commitmentyesChecked when you supply the anchor script.
    A pass is a consistency result, not a performance result

    Every rule here asks the same kind of question: do these records agree with each other? None of them can tell you that money moved, that goods arrived, or that a party did what they said they would. What Bitcoin itself guarantees for a given Pact is written in its enforcement floor, and for a recorded floor the honest answer is: that these terms were committed and not edited afterwards.

    How the commitment is computed

    tag        = SHA256("Drops/PactTransition")
commitment = SHA256(tag || tag || preimage)

    That is the BIP 340 tagged-hash construction. The successor cell descriptor carries the result in its last 32 bytes, and the DPC1 anchor carries it in its last 32 bytes. Both must equal the value computed from the preimage, which is why changing a single byte anywhere in the stated terms breaks the outcome.