140 lines
8.1 KiB
Org Mode
140 lines
8.1 KiB
Org Mode
:PROPERTIES:
|
|
:ID: agora-contracts
|
|
:CREATED: [2026-05-23 Sat]
|
|
:END:
|
|
#+title: Agora — Smart Contracts and the Contract Marketplace
|
|
#+filetags: :passepartout:agora:contracts:revenue:smart-contracts:
|
|
|
|
Agora's infrastructure — DIDs (identity), DIDComm (communication), PDS (state), gate rules (logic), ACL2 (verification) — together form a full smart contract platform. Every piece is already in the architecture. This page describes what contracts are possible, how they generate revenue, and why Agora's approach is structurally stronger than existing platforms.
|
|
|
|
* Why Agora Contracts Are Different
|
|
|
|
Existing smart contract platforms (Ethereum, Solana, Cosmos) verify only that execution followed the rules. Agora's ACL2 prover verifies that the /rules themselves/ are correct with respect to a formal specification. This is strictly stronger:
|
|
|
|
- Ethereum: The contract ran according to the EVM bytecode (execution validity)
|
|
- Agora: The contract is correct with respect to its specification, AND it ran correctly (correctness + execution)
|
|
|
|
This means Agora contracts can encode real-world regulations ([[file:compliance/hipaa.org][HIPAA]], SOC2, [[file:compliance/gdpr.org][GDPR]]) as gate rules and prove that a contract execution satisfies them. No existing platform does this.
|
|
|
|
* What Contracts Enable
|
|
|
|
** 1. Verified Smart Contracts
|
|
|
|
Standard programmable contracts (escrow, swaps, voting, DAO governance) but every execution produces a machine-checkable ACL2 proof.
|
|
|
|
How it works:
|
|
- Contract terms encoded as gate rules
|
|
- State transitions are PDS updates
|
|
- Every transaction runs through the symbolic engine and produces a proof log
|
|
- Any instance can verify any other instance's contract execution by replaying the proof
|
|
|
|
Revenue: Transaction fee per contract execution in the [[file:compute-marketplace.org][compute marketplace]], deployment fee per verified contract, premium for certification weight.
|
|
|
|
Comparison: Ethereum collects ~$20B/yr in transaction fees. Agora's verifiably correct contracts target the same market with a stronger value proposition. The limitation is liquidity, not technology — network effects determine adoption.
|
|
|
|
** 2. Multi-Instance Governance Contracts
|
|
|
|
Organizations running multiple triad instances need contracts that span instances: cross-instance policy, unified compliance, federated identity.
|
|
|
|
Use cases:
|
|
- Enterprise: all instances in the finance department must apply the [[file:compliance/sox.org][SOX]] gate rule set
|
|
- Consortium: each member instance votes on protocol upgrades
|
|
- Supply chain: Instance A verifies shipment, Instance B verifies payment, both must agree
|
|
|
|
Revenue: Enterprise governance tier (annual license), per-instance fee.
|
|
|
|
** 3. Liquid Democracy Infrastructure
|
|
|
|
Agora's liquid democracy enables delegation-based voting where votes can be transferred and proxies can be verified.
|
|
|
|
Use cases:
|
|
- DAO governance (token-weighted or identity-weighted voting)
|
|
- Organizational proxy voting (shareholder meetings)
|
|
- Delegated verification (trust someone's gate rule attestation)
|
|
- Quadratic voting for public goods funding
|
|
|
|
Revenue: Per-vote transaction fee, governance contract setup fee, premium for verified anonymous voting.
|
|
|
|
** 4. Attestation and Reputation
|
|
|
|
DIDs produce verifiable actions. Over time, every DID accumulates a track record of correct verifications, successful contract executions, and honest attestations.
|
|
|
|
Marketplace primitives:
|
|
- Attest that a DID meets certification criteria (identity verification, proof track record, errors-and-omissions insurance)
|
|
- Reputation scores based on verifiable history
|
|
- Reputation staking: put tokens behind your attestation, lose them if wrong
|
|
- Attestation insurance: insure against incorrect attestations
|
|
|
|
Revenue: Attestation fee (one-time or annual), verification fee per reputation query, commission on staked attestations.
|
|
|
|
** 5. Insurance Marketplace
|
|
|
|
If certification carries legal weight (as described in [[file:compute-marketplace.org][compute marketplace]]), then:
|
|
|
|
- Proof insurance: A provider insures their verification results. If a proof turns out wrong, the insurance pays out. Premiums are set by actuarial gate rules based on the provider's track record.
|
|
- Contract execution insurance: Insure against bugs in contract code (even ACL2-verified contracts can have specification errors).
|
|
- Reputation staking pool: A reinsurance pool where multiple providers stake against each other's attestations.
|
|
|
|
Revenue: Premiums, pool fees, actuarial gate rule [[file:licensing.org][licensing]].
|
|
|
|
Why this is defensible: Insurance requires capital and track record. A new entrant cannot bootstrap reputation overnight. The early player accumulates both, creating a moat that compounds with every honest attestation.
|
|
|
|
** 6. Data Sharing and Licensing Contracts
|
|
|
|
PDS-to-PDS data sharing encoded as gate rules. Two instances agree: Instance A may query fact X from Instance B's PDS, subject to gate rule Y, in exchange for Z tokens.
|
|
|
|
Use cases:
|
|
- Personal data licensing: my health data is available to research instances under GDPR-compliant gate rules
|
|
- Enterprise data marketplace: our compliance audit trail is available to customers under NDA gate rules
|
|
- Verified dataset access: this ML training dataset is licensed for non-commercial use, verified by gate rule
|
|
|
|
Revenue: Commission on each data transaction (the compute marketplace extended to data), licensing templates.
|
|
|
|
** 7. Namespace Sub-Leasing and Auction
|
|
|
|
[[file:agora-usernames.org][Premium usernames]] can be sub-leased between DIDs. The registry takes a commission on each lease.
|
|
|
|
Revenue: Commission per lease transaction, auction fees for contested names, premium for verified ownership.
|
|
|
|
** 8. Dispute Resolution
|
|
|
|
When two Agora instances disagree on a contract execution, submit to a verified arbitrator. The arbitrator runs the contract in their own Passepartout and the proof log resolves the ambiguity unambiguously — the dispute is about facts, not interpretations, because the contract terms are formal gate rules.
|
|
|
|
Revenue: Fee per resolution, premium for reputation-weighted arbitration (arbitrators with long track records charge more).
|
|
|
|
* Contract Platform Revenue Summary
|
|
|
|
| Primitive | TAM proxy | Revenue model | Phase | Dependency |
|
|
|----------+-----------+--------------+-------+------------|
|
|
| Smart contracts (general) | $20B/yr (Ethereum) | Transaction fees | End State | Installed base |
|
|
| Contract templates | New market | Per-template sale | Zero | Gate rule SDK |
|
|
| Governance (multi-instance) | New market | Annual license | Zero | [[file:stoa.org][Stoa]] premium |
|
|
| Liquid democracy | New market | Per-vote fee | End State | Installed base |
|
|
| Attestation | New market | Per-attestation | Zero | DID registry |
|
|
| Insurance marketplace | $1T+ (global insurance) | Premiums | End State | Installed base + capital |
|
|
| Data sharing | New market | Commission | Both | PDS + DIDComm |
|
|
| Namespace sub-leasing | Small | Commission | Zero | Username registry |
|
|
| Dispute resolution | New market | Per-resolution | End State | Installed base |
|
|
|
|
Key insight: Contract templates, attestation, and multi-instance governance can ship in Phase Zero. They require only the existing Agora infrastructure (DIDs, PDS, gate rules) — no full Lisp Machine needed. These seed the contract economy before the smart contract platform ships.
|
|
|
|
* Relationship to Compute Marketplace
|
|
|
|
The compute marketplace and the contract platform reinforce each other:
|
|
|
|
- Contracts need compute to execute (marketplace demand)
|
|
- Compute providers need contracts to structure their offerings (marketplace supply)
|
|
- Attestation bridges them: a compute provider's track record is a verifiable contract history
|
|
- Insurance prices compute risk based on attestation
|
|
|
|
The triad's network effects compound when all three layers (compute, contracts, attestation) are active simultaneously. Any one layer without the others is weaker — together they create the [[file:verification-monopoly.org][verification monopoly]].
|
|
|
|
* References
|
|
|
|
- [[file:agora.org][Agora overview]]
|
|
- [[file:agora-usernames.org][Premium username registry]]
|
|
- [[file:pds-as-a-service.org][PDS as a service]]
|
|
- [[file:compute-marketplace.org][Compute marketplace]]
|
|
- [[file:revenue-hub.org][Revenue streams overview]]
|
|
- [[file:verification-monopoly.org][Verification monopoly]]
|