TradeTrust

  • Name: TradeTrust
  • URL: https://github.com/TradeTrust/tradetrust
  • Category: electronic-transferable-record framework / trade-document title-transfer infrastructure / verifiable-documents control plane
  • Tags: ethereum-ecosystem
  • Summary: TradeTrust is a higher-layer trade-document control plane built on verifiable-document plumbing. The useful split is between document proof, token-registry issuance, beneficiary-versus-holder role separation, and title-escrow-managed transfer workflows. Keep it because it shows where document attestation stops and title transfer starts.
  • What it does:
    • Wraps and verifies TradeTrust verifiable documents using Merkle proofs and signature-based or onchain publication paths
    • Supports standard document-store issuance and revocation for non-transferable verifiable documents
    • Deploys token registries for transferable records rather than only document stores for static attestations
    • Mints transferable records against token registries so documents become unique onchain records tied to holder and beneficiary roles
    • Creates title-escrow contracts during minting to manage title-transfer workflows between owners and holders
    • Exposes explicit transferable-record actions such as change holder, nominate change of owner, endorse transfer, reject transfer, return to issuer, and accept/reject return
    • Guides implementers through creator flows for deploying token registries, generating DID material, and managing transferable documents end to end
    • Separates document creation, registry deployment, verification, and transfer workflows across library, core SDK, CLI, and tutorial repos
  • Key claims:
    • The TradeTrust README still frames the project in broad document-attestation terms, but the stronger primary signal is in tradetrust-core and the CLI surface, where the system clearly expands into transferable-record workflows rather than stopping at generic document verification.
    • The tradetrust-core README explicitly separates ordinary verifiable-document issuance from transferable-record minting through token registries. That matters because the main reusable mechanism is not only Merkle-root publication, but the split between static attestation and title-bearing record.
    • The title-escrow layer is the decisive reason to keep TradeTrust separate from OpenAttestation. The core README says minting creates a Title Escrow with an initial owner and holder, and later transfer logic runs through nomination and endorsement methods rather than through a generic NFT transfer alone.
    • The beneficiary-versus-holder distinction is analytically important because it makes ownership and possession/control different surfaces. That is more useful than generic tokenized document language because it exposes where transfer approval and operational custody can diverge.
    • The CLI command set reinforces that TradeTrust is a workflow framework, not just a file format. It includes commands for issuing to token registries, changing holder, nominating and endorsing owner changes, rejecting state transitions, and returning documents to issuers.
    • The creator tutorial is another strong signal that TradeTrust should stay in the active corpus: it walks developers through creating, deploying, and managing transferable documents, which makes the framework legible as operational infrastructure rather than as a passive standard.
    • TradeTrust belongs in the active corpus because it separates at least three layers that generic verifiable documents coverage often flattens together: document integrity and issuer proof, registry-level issuance and minting, and title-escrow-mediated transfer control. If it stayed folded into OpenAttestation alone, the ownership and transfer-governance surfaces would be much easier to miss.
  • Whitepaper: No standalone whitepaper surfaced in this pass. The strongest primary materials were the main TradeTrust README, the tradetrust-core README, the CLI README, and the creator tutorial; see ../whitepapers/tradetrust-primary-sources-2026-05-12.md.
  • Sources:

Internal linkages