Prototype docs. APIs may change while SDKs and verifier libraries harden.
Attestations
Each bond maintains an append-only chain of BIP340-signed attestations.
An attestation:
- identifies the bond,
- links to the previous attestation,
- commits to the next signing nonce,
- carries Bitcoin header context, and
- commits to a payload root.
What is signed
The signed body commits to:
bond_idprevheightnext_nonce- Bitcoin block tip and headers
- payload hash
That makes the update chain explicit and makes conflicting updates detectable.
Nonce commitments
Each attestation commits to the nonce that must be used by the next attestation. If a signer equivocates by reusing a nonce across conflicting messages, the evidence can expose the signing key.
Reorg context
Attestations carry Bitcoin headers so validators can reason about chain context. Validation checks that the header vector is contiguous, has valid proof of work, and improves chainwork when switching tips.
Limits and rejects
The validator enforces attestation and payload size limits. Common reject categories include invalid signatures, invalid headers, unexpected nonces, broken chain linkage, and oversize payloads.