OpenWitness.org

Blueprint for
Trusted Institutions

How to build a public service that is accountable without authority, funded without fees, and governed without governors.

The Promise

Why a blueprint?

Traditional institutions earn trust through reputation, regulation, and legal enforcement. These mechanisms work, but they concentrate authority in gatekeepers. When gatekeepers fail, so does the trust.

OpenWitness takes a different approach: structural accountability. Every design decision is made so that trust is a measurable outcome of the system's architecture, not a promise from its operators. The entire service is designed to be copied, forked, and replaced by anyone who can run it better.

This page documents the institutional architecture behind OpenWitness. It is both an explanation and an invitation: if this design works, use it. If it has flaws, fork it and fix them.

Free by design Accountable by protocol Open to competition Forkable as governance
Architecture

Five layers of institutional trust

The architecture is organized as a stack. Each layer builds on the one below it. The cryptographic foundation carries everything; the trust competition layer governs everything.

Layer 5
Trust Competition Forkability as governance. Race-to-bottom trust economics. No lock-in.
Layer 4
Capacity & Access Subscription tiers. Per-wallet rate allocation. Anti-sybil via contribution tracking.
Layer 3
Economic Model Fuel bonding curves. Smart-contract-governed A/B split. Founder reward.
Layer 2
Identity & Governance Founder key hierarchy. Signed governance tree. Bootstrap protocol.
Layer 1
Cryptographic Foundation Merkle trees. Dual anchoring (EVM + eIDAS qTSA). Membership shielding.
Layer 1

Cryptographic Foundation

Every claim the service makes is anchored to independently verifiable roots of trust. No claim depends on the operator's word alone.

Dual anchoring

Each batch of submitted hashes is anchored to two independent trust roots simultaneously: an EVM blockchain (Ethereum) and an eIDAS-qualified Timestamping Authority. One root is governed by cryptographic consensus, the other by EU regulatory oversight. A verifier who trusts either system can validate the timestamp.

Step 1 Collect Hashes accumulate during the epoch window
Step 2 Seal Merkle tree built, root computed
Step 3 Anchor Root published to EVM + qTSA in parallel
Step 4 Witness Per-hash inclusion proofs minted and stored

Membership shielding

Standard Merkle proofs leak sibling hashes, enabling membership inference attacks. OpenWitness shields each leaf with a per-leaf random nonce before building the tree. Proof siblings are shielded values that cannot be reversed without the submitter's nonce. Verification stays self-contained: the witness carries the nonce and the verifier recomputes locally.

Witness shape

For each submitted hash, the service produces a witness: a chain of Aqua Protocol revisions linking the client's original hash to the anchored root. The witness is a standalone proof artifact; it carries everything a verifier needs. No callback to the service is required.

Layer 2

Identity & Governance

The service has a cryptographic identity rooted in a founder key. Every governance action is a signed message. Unsigned instructions carry no identity, no accountability, and no basis for verification.

Key hierarchy

Founder Key (cold, external, root trust) Three responsibilities only: a) Declare and authorize operational keys b) Receive founder reward (1% success incentive) c) Authoritative smart contract interactions Delegates to: Authorization Key (hot, operational) Authenticates CLI sessions for governance uploads Service Identity Key (hot, operational) Signs witnesses, identity tree, SIWE challenges Anchors Merkle roots to EVM Publishing Wallet (hot, operational, deferred) Reviews and operates governance proposals

Bootstrap protocol

The governance tree is built and signed externally by the founder, uploaded via an authenticated CLI session, and persisted permanently. Two separate verifications must pass: the CLI session must be authenticated by the authorization key, and the governance tree must be signed by the founder key. Both are required.

Founder Build & Sign Governance tree built via CLI, signed with founder key
Operator Authenticate CLI session authenticated with authorization key
Service Verify & Ingest Both signatures checked; tree persisted; state transitions

Governance tree

The governance tree is a standard Aqua tree served publicly at /.well-known/aqua-governance. It contains signed declarations for the founder's identity, contract addresses, beneficiary address, and trust delegations. All governance content is verifiable by anyone using the same tools the service uses for its own timestamps.

Layer 3

Economic Model

The service is free. Contributions are "fuel" that powers the machine, not fees charged for access. The economic model is designed so that funding scales the service without creating a paywall.

Fuel, not fee

The service provides timestamping at no charge. Contributors send fuel to increase the service's anchoring capacity and publication speed. More fuel means faster epochs, not gated access.

The A/B split

All incoming fuel is split between two purposes by a deterministic smart contract:

(A) Anchoring On-chain

  • Gas for EVM anchor transactions
  • Costs for qTSA requests
  • BTC anchoring (planned)
  • Verifiable by anyone on-chain

(B) Operations Aqua-tracked

  • Infrastructure and compute
  • Development and maintenance
  • Coordination and outreach
  • Accountable via Aqua-on-Aqua

Bonding curve

The operational share follows a logarithmic decay from 50% (bootstrap phase, low income) to 2% (mature phase, high income). A single tuning parameter shapes the curve. As the service matures and income grows, a larger share goes directly to anchoring and a smaller share to operations, ensuring efficiency pressure scales with success.

Phase Operational share Anchoring share Condition
Bootstrap 50% 50% Below income threshold
Growth 50% to 2% 50% to 98% Logarithmic decay as income rises
Mature 2% 98% Above half-life income
Terminal 1% 99% After both founder reward caps are hit

Two chains, one model

ETH and BTC are the same economic model running independently in two separate worlds. They share only the BTC difficulty epoch (~2 weeks) as an evaluation clock. No exchange rates, no cross-chain binding, no shared balances. A single Ethereum smart contract governs the fuel split for both chains, with BTC bridged in via wrapped BTC.

Founder reward

The founding team receives 0.5% per chain (1% total), capped at 10 BTC + 500 ETH. The reward activates only when both chains reach maximum publication rate, ensuring the founders earn only when the service is operating at peak capacity. A competitor who skips the founder reward starts with a 1 percentage point structural advantage on fuel efficiency.

Layer 4

Capacity & Access

The service has finite anchoring capacity determined by its fuel balance and publication rate. The capacity layer allocates this budget across contributors.

Free tier

Every wallet gets a baseline allocation at no cost. The free tier is a structural commitment: the service is free by design, not free as a trial. Rate limits prevent abuse without creating a paywall.

Contribution scaling

Wallets that contribute fuel receive higher hash rate allocations. The mapping from contribution to allocation follows a logarithmic curve matching the fuel model's character. This is "fuel, not fee": contributors increase the whole service's capacity while earning priority for their own usage.

Wallet pool

The service maintains a pool of up to 500 active wallets. A three-tier eviction strategy (funded, active, idle) ensures capacity goes to wallets that are actively using and supporting the service. Two orthogonal leaderboards (ETH and BTC) provide transparent, real-time visibility into who is fueling the machine.

Layer 5

Trust Competition

This is the governance layer. It has no voting, no council, and no on-chain enforcement of off-chain spending. Instead, it relies on competitive pressure from an open market of potential operators.

The core thesis

The spec and service are open and meant to be copied. This is not a side effect of open source. It is the governance model.

Two accountability domains

Hash World (A) Self-accountable

  • Anchoring transactions on-chain
  • Verifiable by default
  • No trust required
  • Governed by deterministic math

Operational World (B) Competition-governed

  • Infrastructure, development, coordination
  • Cannot be verified purely on-chain
  • Governed by two mechanisms below
  • Backstop: forkability

Mechanism 1: Aqua-on-Aqua accounting

The operational budget is tracked using the Aqua Protocol itself. The service that provides data integrity uses its own product to account for its own operations. Operational decisions, expenditures, and resource allocation are captured as timestamped, immutable hash chains. Anyone can audit the operational record using the same tools they use to verify their own timestamps.

Mechanism 2: Competitive accountability

Because the spec is complete and the code is open, any team can fork the service. Operators compete on trust, efficiency, and reliability. The most trusted operator attracts the most fuel. This creates a virtuous cycle where trust directly translates to service quality.

No structural advantage for the founders

Potential advantage Why it does not hold
First mover Open spec means latecomers start fully informed
Code ownership Open source; forks inherit all engineering
Brand recognition Trust is re-earned continuously; brand is a lagging indicator
User lock-in Service is stateless for users; switching cost is near zero
Founder reward 1% total, capped, conditional on peak operation
Honesty

Open Questions & Gaps

A blueprint that hides its gaps is not a blueprint; it is marketing. These are the areas where the institutional design is incomplete, unresolved, or deferred. Each gap is a research question, not a failure.

Dispute Resolution Open
No mechanism for resolving conflicts between operators, or between operators and contributors. The trust competition model assumes exit (fork and leave) as the sole recourse.
BTC Bridge Mechanism Open
How to pipe Bitcoin fuel into the Ethereum smart contract trustlessly. Options range from custodial (wBTC) to threshold (tBTC v2) to experimental (BitVM bridges). Unresolved.
Governance Decision Rounds Deferred
The proposal, review, and approval flow for operational decisions is designed but not implemented. Depends on the publishing wallet delegation and the org smart contract.
Key Rotation Deferred
The founder key can be rotated once, anchored to the org smart contract. The contract does not exist yet. Without rotation, founder key compromise is catastrophic.
Contribution Tracking Open
Should per-wallet contribution tracking live on-chain (transparent but expensive) or off-chain via Aqua-on-Aqua (cheaper but requires the trust competition model for accountability)? The biggest architectural decision remaining.
External Audit Framework Open
Aqua-on-Aqua accounting for the operational budget is self-referential. External audits and cross-operator verification break the circularity, but no protocol for how these audits happen is defined.
Migration Protocol Open
Forkability assumes near-zero switching cost. There is no defined protocol for a contributor to port their proof history or contribution record to a competing operator.
Natural Monopoly Risk Open
Whether the service has natural monopoly dynamics at small scale is an empirical question. If only one operator is economically viable, the trust competition model becomes theoretical.
Fork It

How to run your own instance

The blueprint is only credible if you can act on it. Everything needed to run a competing instance is public.

Component Where License
Protocol specification aqua-spec Open
Reference SDK (Rust) aqua-rs-sdk Apache-2.0
This service aqua-timestamps Apache-2.0
Auth library aqua-rs-auth Apache-2.0
Operational design This page Public domain

Generate a secp256k1 key, configure the dual anchors, deploy the Docker image, and point contributors to your instance. The bonding curve, governance bootstrap, and trust competition model apply identically to any operator.