Drops Protocol documentation

    Conformance

    What compatible actually means

    Three classes, each a superset of the one before. Every requirement is written so that it either passes or fails against the test vectors. If a statement here cannot be tested, it does not belong on this page.

    The three classes

    Class A: Reader

    Decodes a Drops leaf and reports its fields correctly. Suitable for a wallet preview, an inspection tool, or a decoder. Makes no claim about whether a Drop exists on chain.

    Class B: Verifier

    Everything in class A, plus full Taproot commitment verification against the spent output. May state that a given reveal input is a valid Drop.

    Class C: Indexer

    Everything in class B, plus confirmation policy, identity assignment, custody projection and reorganisation handling. May serve a record set that others rely on.

    An implementation should state which class it claims. A tool that decodes leaves is useful and honest as a class A implementation; a tool that decodes leaves and calls the results verified Drops is neither.

    Class A requirements

    1. C-A1

      must reject any script that does not decompile to exactly ten chunks in the required arrangement. Test: IV-9, IV-10.

    2. C-A2

      must require the minimal push encoding for every field, and must reproduce the input script byte for byte when re-serializing the parsed fields.

    3. C-A3

      must reject a one-byte body of 0x81 or 0x01 through 0x10, and must accept a one-byte body of 0x00. Test: IV-5.

    4. C-A4

      must accept only the markers drops and drops-pact, and must reject bip110-op-drop. Test: IV-2.

    5. C-A5

      must enforce the content-type grammar, the ASCII requirement and the 80-byte cap, and must reject parameters and uppercase. Test: IV-3, IV-4.

    6. C-A6

      must recompute SHA-256 of the body and compare it with the hash field. Test: IV-1.

    7. C-A7

      must validate the creator key as a point on secp256k1, not by length alone. Test: IV-8.

    8. C-A8

      must enforce the body length range of 1 to 256, and must accept a 256-byte body encoded with OP_PUSHDATA2. Test: IV-6, IV-7.

    9. C-A9

      must not describe a decoded leaf as a verified Drop, a confirmed Drop, or an owned Drop.

    10. C-A10

      should decode the Pact Seed and Pacts reference body profiles when the relevant content type is declared, applying the byte-exact re-encoding rules for both.

    Class B requirements

    1. C-B1

      must satisfy every class A requirement.

    2. C-B2

      must require a witness of exactly three items with a signature of 64 or 65 bytes, and must reject an input carrying a Taproot annex. Test: CT-9.

    3. C-B3

      must verify that the spent previous output is a 34-byte native P2TR script. Test: CT-1.

    4. C-B4

      must validate the control block length rule and the 128-hash path limit. Test: CT-2, CT-3.

    5. C-B5

      must accept only Tapleaf version 0xc0. Test: CT-4.

    6. C-B6

      must validate the internal key as a curve point. Test: CT-5.

    7. C-B7

      must compute the tapleaf hash, fold the merkle path with sorted branch hashing, apply the TapTweak, and compare both parity and the x-only output key. Test: CT-6, CT-7.

    8. C-B8

      must treat any error raised during verification as a rejection.

    9. C-B9

      must distinguish an unresolved candidate, where the previous output could not be fetched, from a proven rejection. Test: CT-8.

    10. C-B10

      should use a constant-time comparison for the output key.

    Class C requirements

    1. C-C1

      must satisfy every class B requirement.

    2. C-C2

      must record an artifact only at or beyond its configured confirmation depth, and must refuse a mainnet depth below six. Test: CT-10.

    3. C-C3

      must derive identity from the reveal input index and emit it lowercase in the full portable form.

    4. C-C4

      must assign two distinct identities to a transaction that reveals two Drops on two inputs.

    5. C-C5

      must scope records by network and must not resolve an identity from another network.

    6. C-C6

      must set the initial custody outpoint to output 0 of the reveal, and must apply the P2WPKH and P2TR positive-value test on every subsequent move.

    7. C-C7

      must mark custody burned when a spend does not produce a supported output 0, and must keep the record itself readable.

    8. C-C8

      must maintain a block journal and, on divergence, must roll back and rebuild projections from surviving immutable records rather than patching them.

    9. C-C9

      must stop with a named reason rather than guess when a reorganisation exceeds its budget or the common ancestor is ambiguous.

    10. C-C10

      must publish its network, confirmation depth and indexed height alongside the data it serves.

    11. C-C11

      must not let a recorded rejection alter any other record's state.

    12. C-C12

      must apply the passive-content serving policy if it serves bodies over HTTP, defaulting unknown and active types to an opaque attachment.

    13. C-C13

      should publish custody integrity counters so that projection drift is measurable rather than assumed.

    14. C-C14

      should treat a change to confirmation depth that intersects indexed history as an audited replay, not a silent reinterpretation.

    Pacts conformance

    Optional, and independent of the classes above. An implementation that reads Pact records should be able to say which of these it does.

    1. C-P1

      must enforce the 184-byte Seed length, the DPSE magic, zero reserved bytes at offsets 4 and 7, known network and floor tags, and zero engine padding. Test: PV-6 through PV-10.

    2. C-P2

      must enforce the 176-byte Cell descriptor length, the DPCL magic and zero reserved bytes. Test: PV-3 through PV-5.

    3. C-P3

      must enforce the 245-byte transition preimage length and compute the commitment as a tagged hash under Drops/PactTransition. Test: PV-12.

    4. C-P4

      must apply outcome rules P-1 through P-9 in full before describing an outcome as verified, and must state which rules it applied when it applies only some. Test: PV-1, PV-2, PV-11.

    5. C-P5

      must surface the Seed's enforcementFloor anywhere it presents a Pact, and must not imply a stronger guarantee than the floor states.

    6. C-P6

      must not present a Pacts surface as offering execution, custody, authorization, signing, broadcast or value-bearing authority while the capability contract reports mode: reference.

    Self-certification, honestly stated

    There is no certification authority for Drops. What is available is a fixed set of vectors and a fixed set of requirements, so an implementation can publish exactly which class it claims and which vectors it passes. That is worth more than a badge.