What is stored on chain ?

  1. Home What is stored on chain ?

The chain stores metadata about the agreement, not the document itself.

Stored on-chain (state)

  • Agreement ID (agreementId) — the ERC-1155 token id for that agreement
  • Document hash (docHash) — a bytes32 hash of the file (proof the exact bytes match, without uploading it)
  • Creator wallet (creator) — who created the agreement entry
  • Mode flag (isShares)
    • false = badge mode (each party mints 1)
    • true = shares mode (each party mints their unit amount)
  • Optional metadata URI (uri) — e.g., ipfs://… or https://… (you control what you put here)
  • Party list (address[]) — the invited party wallet addresses
  • Units per party (units[agreementId][party]) — used in shares mode (or defaults to 1)
  • Acceptance flag per party (accepted[agreementId][party]) — whether that party has accepted/minted yet
  • Token balances (balanceOf(party, agreementId)) — minted holdings for each party

Stored on-chain (events/logs)

  • AgreementCreated(agreementId, creator, docHash, isShares, uri)
  • PartyInvited(agreementId, party, units)
  • PartyAccepted(agreementId, party, mintedAmount)
  • Standard ERC-1155 TransferSingle/TransferBatch mint events

What is NOT stored on-chain

  • The PDF/Doc/XLS contents
  • Names, emails, addresses, signatures, IDs (unless you put them into the uri or hash them yourself)
  • Any account information.

Privacy note

The party wallet addresses are public once included which is part of the proof of the party.

1) Verification Certificate (IPFS)

This is a machine-readable proof record, not the agreement itself.

It contains:

  • Agreement ID
  • Cryptographic document hash (SHA-256)
    (used to prove a document existed without revealing it)
  • Creator wallet address
  • Party wallet addresses (shortened)
  • Token ID(s) and units
  • Blockchain (Base)
  • Contract address
  • Transaction hash
  • Timestamp
  • Verify link + QR code

It does NOT contain:

  • The agreement file
  • Contract terms
  • Personal information
  • Signatures
  • Attachments

The certificate is pinned to IPFS so it can be independently referenced and verified later.

2) Token Metadata (IPFS)

This is standard ERC-1155 metadata so wallets and explorers can display the token correctly.

It contains:

  • Token name and description
  • Link to the verification page
  • Link to the IPFS certificate
  • Chain ID and contract address
  • Non-sensitive attributes (e.g., “Agreement ID”, “Mode”)

This metadata is stored on IPFS and its URI (ipfs://…) is written on-chain at the time of minting.

What is NOT stored on IPFS

  • ❌ Agreement documents
  • ❌ PDFs, DOCs, or uploads
  • ❌ Legal text or clauses
  • ❌ Personal identity data
  • ❌ Signatures or IDs
  • ❌ Emails or names

All sensitive content stays off-chain and under your control.

Why IPFS is used at all

  • Creates a tamper-evident, third-party-verifiable reference
  • Allows auditors, counterparties, and courts to verify:
    • a specific document existed
    • at a specific time
    • tied to specific wallets
  • Improves wallet / explorer display without leaking data
  • Avoids vendor lock-in (IPFS is content-addressed)