IPTF
production offchain I2I

ICMA Bond Data Taxonomy (canonical terms/events)

Use the ICMA Bond Data Taxonomy as the canonical schema for bond terms and lifecycle events. A shared data model avoids fragmentation across issuance platforms, registrars, and regulators, and provides a stable foundation for attestations and zero-knowledge proofs over bond data.

CR
None
Censorship Resistance
O
Yes
Open Source
P
Full
Privacy
S
High
Security
CROPS context
Censorship Resistance
Schema governance sits with a single standards body (ICMA). Could reach medium if the schema is published as a permissionless open registry with attestation-anchored contributions and no approval gate.
Open Source
Open specification, publicly documented. Implementations can reuse the schema without licensing barriers, though schema evolution is gated by the standards body.
Privacy
Schema itself contains no participant data; only field definitions. Raw bond data stays off-chain, with only hashes anchored on-chain, so the pattern does not expose confidential details.
Security
Rides on the correctness of off-chain validators and the integrity of hash anchoring. Well-defined schemas reduce integration errors and make regulator reconciliation straightforward.
Works best when
You want machine-readable bond terms and lifecycle events across tools.
Multiple issuance platforms need to interoperate without bespoke mappings.
Avoid when
A jurisdiction or domain mandates a different canonical schema.
Intent

Use the ICMA Bond Data Taxonomy as the canonical schema for bond terms and lifecycle events. A shared data model avoids fragmentation across issuance platforms, registrars, and regulators, and provides a stable foundation for attestations and zero-knowledge proofs over bond data.

Components
  • Canonical schema defines bond terms (identifiers, parties, cash flows, covenants) and lifecycle events (issuance, coupons, redemption, restructuring).
  • Schema validator checks that bond records conform to the canonical definitions before they are signed, hashed, or anchored.
  • Compression layer converts verbose representations (for example XML) into binary or compact serialization for efficient on-chain anchoring.
  • Registrar integration maps internal registrar records to the canonical schema so existing systems can emit conformant data without rewriting their back office.
  • Attestation anchor posts hashes of conformant records to an on-chain attestation registry so any verifier can check that a disclosed document matches what the registrar recorded.
Protocol
1
[operator] Author bond terms and lifecycle events in the canonical schema.
2
[operator] Validate the record against the schema and compress for storage.
3
[operator] Store the record (on-chain hash anchor, off-chain canonical payload).
4
[auditor] Use the same schema when preparing selective-disclosure proofs or attestations.
5
[regulator] Verify consistency between disclosed payloads and on-chain hash anchors.
Guarantees & threat model

Guarantees:

  • Interoperable, regulator-friendly bond data across platforms.
  • Easier proofs and attestations over common fields without bespoke per-issuer schemas.
  • Clean baseline for composing with hash-anchored registries and zero-knowledge disclosure patterns.

Threat model:

  • Schema governance integrity. If the standards body publishes conflicting revisions, validators may diverge on what counts as conformant.
  • Registrar mapping correctness. A mismapping at integration time can silently break consistency between internal records and canonical output.
  • Out of scope: data confidentiality. The schema is a structural artifact, not a privacy tool; confidentiality must come from accompanying patterns (hash anchoring, selective disclosure, ZK proofs).
Trade-offs
  • Up-front mapping effort is required to wire existing registrar systems into the canonical schema.
  • Schema extensions for new product types (complex derivatives, non-standard covenants) need standards-body involvement, which can lag market innovation.
  • Not a privacy mechanism on its own. Must be paired with hashing, attestation, or zero-knowledge patterns to protect the underlying data.
Post-quantum
low risk
Vector: Hash-based anchoring is not directly affected. Any ECDSA-signed off-chain attestations over BDT records are vulnerable to a CRQC, but the canonical schema itself has no cryptographic dependency.
Mitigation: Use post-quantum signatures for attestations over BDT records; hash-based commitments for on-chain anchoring remain safe.
Example

An issuance platform publishes bond terms in the canonical schema. The registrar validates the record and anchors its hash via an on-chain attestation registry. A regulator later receives the full payload off-chain and verifies the hash matches the on-chain anchor, confirming the record has not been altered since issuance.