Skip to main content

Blockchain feasibility analysis (Matou)

This document explains what parts of Matou's work should go on the Cardano blockchain and what should stay off-chain. It uses simple language and gives practical steps Matou can follow.

Principles we will follow​

  • Put high-impact actions on-chain: Money moves, token supply changes, and final governance results should be recorded on-chain.
  • Keep private and sensitive info off-chain: Personal data, cultural knowledge, and internal discussion should not be public on-chain.
  • Prove, don't over-share: Store small proofs or hashes on-chain. Keep full data off-chain where it is safer and easier to manage.
  • Keep costs and tools simple: Use basic Cardano features first (native tokens, multi‑sig scripts, transaction metadata). Add more complex Plutus scripts only when needed.
  • Stay flexible: Keep proposal drafting and discussion off-chain so the process can evolve without changing code.
  • Good user experience: Reduce signer workload, use reliable wallets and scripts, and automate repeat tasks.

What should be on-chain (Cardano)​

  • Treasury custody and spending

    • Hold funds at a multi-signature script address (time-lock + signer keys) or a small Plutus script that enforces signing rules.
    • Approve and record every spend on-chain. Use batched transactions for routine payouts.
    • Add time delays (time-locks) for high-risk actions so the community can react if needed.

  • Token lifecycle (CTR and UTIL)

    • Use Cardano native tokens. Control minting and burning with a minting policy (native or Plutus).
    • Fix supply caps and vesting rules in the policy or in a simple controller script if needed.

  • Final governance results (not the discussion)

    • For each proposal, publish on-chain: a stable proposal ID, the final result, vote tallies per House, and a content hash.
    • Use transaction metadata and/or update a small "registry UTxO" (a Plutus or simple script that holds the latest state in its datum).

  • Critical roles and parameters

    • Record signer lists and thresholds (for the treasury script), emergency pause flags, and key governance parameters on-chain.
    • Use a script-controlled parameters UTxO so changes are transparent and require proper authorization.

  • Issuer/attestation anchors (optional)

    • Keep a list of trusted credential issuers (public keys or DIDs) on-chain.
    • Store only hashes of revocation lists or schema IDs; keep actual credentials off-chain.

What should stay off-chain​

  • PII and sensitive cultural information

    • Identity documents, names, addresses, whakapapa context, or internal conversations.

  • Proposal content and discussion

    • Full text, attachments, comments, and media live in a document system or database. Store a content hash and link on-chain.

  • Contribution logs and scoring

    • Day-to-day records and reviews stay in an off-chain database. Periodically publish a hash (data root) on-chain to prove integrity.

  • Identity verification details

    • Use Verifiable Credentials (VCs) or similar. Show proofs off-chain, and only anchor issuer keys or revocation hashes on-chain if needed.

  • Analytics and monitoring

    • Keep dashboards, metrics, and alerts off-chain.

How this maps to Matou (Cardano-specific)​

  • Three Houses governance (Contributor, Community, Elders)

    • Voting: Run voting off-chain with clear rules per House (by token, reputation, or allowlist). Export final results.
    • Result anchor: After a vote closes, submit a transaction that stores (a) proposal ID, (b) tallies by House, (c) pass/fail result, and (d) a content hash of the full proposal package. Use transaction metadata and/or update a registry UTxO.
    • Execution: If a proposal passes and requires funds or parameter changes, perform an on-chain transaction from the treasury script. The signed transaction references the proposal anchor for traceability.

  • Treasury management

    • Use a multi-signature script address for custody (e.g., M-of-N keys with optional time-locks). Store the current signer set and threshold as on-chain parameters in a parameters UTxO.
    • Batch routine payouts (multiple outputs per transaction). For recurring payments, pre-build and schedule transactions for signer review.

  • Token distribution (CTR/UTIL)

    • Compute recipient lists off-chain. Two options:
      1. Direct sends: Create batched transactions that pay many recipients at once over several transactions if needed.
      2. Claim model: Create "voucher" outputs or use a simple claim script so recipients can claim their tokens later. Keep claims simple and low-fee.

  • Retroactive value rewards

    • Keep detailed evidence off-chain. Periodically publish a data root (hash) on-chain. Fund payouts via on-chain transactions approved by the treasury script.

  • Identity and participation controls

    • Do not store identities on-chain. If needed, keep a small on-chain allowlist of approved issuers (public keys or DIDs). Off-chain systems verify VCs and produce allowlists for each vote.

  • Policy and parameter changes

    • Keep a GovernanceParameters UTxO controlled by a script. Examples: quorum percentages, House thresholds, emergency pause. Only a passed proposal plus authorized signers can update it.

Cardano design choices and tools​

  • Chain: Cardano mainnet. Keep actions minimal and batched to reduce fees and chain load.
  • Smart contract style: Start with native scripts (multi-sig and time-lock). Use Plutus V2 only when logic requires it (e.g., registry UTxO with datum updates, simple claim scripts).
  • Data anchoring: Use transaction metadata (with a stable schema) to store small fields and hashes. For stateful records, use a registry UTxO pattern where a script updates a single output that carries the latest datum.
  • Wallets and signing: Use well-supported wallets for signers (CIP‑30 compatible). Keep hardware keys for security and allow quick key rotation by changing the signer set in the parameters UTxO.
  • Off-chain services: Use a database or document store for content, plus IPFS/Arweave if you want content-addressed storage. Always store a content hash on-chain.

Cost expectations (rough)​

  • Publishing results in transaction metadata: low ADA cost per transaction.
  • Updating a parameters or registry UTxO (small datum): low ADA cost per update.
  • Batched distributions: costs scale with outputs and transaction size. Split into several transactions if needed.

Phased roadmap​

  • Phase 0 (Now): Multi-signature treasury on Cardano; keep governance off-chain; publish monthly a summary with transaction metadata hashes.
  • Phase 1: Add proposal result anchoring (metadata + registry UTxO). Start batched distributions for grants and rewards.
  • Phase 2: Add GovernanceParameters UTxO and simple execution guards (scripts check that a referenced proposal passed before allowing certain actions).
  • Phase 3: Optional credential issuer anchors and simple claim scripts. Consider selective on-chain voting only for highest-stakes decisions.

Risks and how to reduce them​

  • Key compromise: Use hardware wallets, spread signers across Houses, rotate keys quickly by updating the signer set, and keep an emergency pause.
  • Privacy leaks: Only store hashes and minimal fields on-chain. Never store PII or sensitive cultural context.
  • Censorship/resilience: Pin IPFS with multiple providers, mirror critical docs to Arweave, and always publish content hashes.
  • Legal/regulatory: Get legal advice for token use. Document treasury policies and keep clear audit trails.

Operational checklist​

  • Create proposal off-chain. Compute a content hash.
  • After vote closes: export results, create a small JSON summary, compute a data root hash, and submit an on-chain transaction with metadata and/or update the registry UTxO.
  • For distributions: compute recipients and amounts, build batched transactions, and execute from the treasury script.
  • Monthly: publish a summary transaction that references the proposals and parameter changes made that month.

Minimal on-chain data fields (suggested)​

  • proposalId
  • houseTallies (Contributor, Community, Elders)
  • quorumFlags
  • result (passed/failed)
  • contentHash (SHA‑256 or Blake2b)
  • dataRoot (hash of full result set)

Glossary (Cardano)​

  • UTxO (Unspent Transaction Output): The basic unit of funds on Cardano. Transactions consume existing UTxOs and create new ones.
  • eUTxO (Extended UTxO): Cardano's model that lets scripts attach data (datum) and conditions to UTxOs.
  • Plutus script: On-chain program that checks if a transaction meets certain rules before spending a UTxO.
  • Datum: Small piece of data attached to a script UTxO that represents its state.
  • Redeemer: Data provided when spending a script UTxO to explain the action being taken.
  • Native token: A token on Cardano that does not need a smart contract to exist. Controlled by a minting policy.
  • Minting policy: Rules (native or Plutus) that control when and by whom tokens can be minted or burned.
  • Multi-signature (multi-sig): Requiring multiple keys to approve a transaction. Implemented with native scripts or Plutus.
  • Time-lock: A rule that prevents spending before or after a specific time/slot.
  • Transaction metadata: Small key/value data attached to a transaction, useful for anchoring hashes and IDs.
  • Registry UTxO: A pattern where a single script-controlled UTxO holds the latest state (in its datum) for things like parameters or proposal records.
  • Reference script: A feature that allows a script to be referenced without including full code in every transaction, reducing size and cost.
  • CIP‑30: A Cardano standard for dApp-wallet interaction (browser wallets).
  • CIP‑68: A standard for structured NFTs that store data in datums; useful for on-chain records.
  • Verifiable Credential (VC): A tamper-evident digital credential. Usually stored off-chain; proofs can be shown when needed.
  • DID (Decentralized Identifier): A standard for identifiers that are controlled by the owner, not a central registry.
  • Content hash: A hash (e.g., SHA‑256, Blake2b) that uniquely represents a file or record.

This approach gives Matou strong transparency for the most important actions, protects privacy, keeps costs low, and stays close to standard Cardano tooling. It can be expanded later without breaking the core design.