:PROPERTIES:
:ID:       64708e1f-00e9-4cb7-b44b-ea0b98e5296d
:ID:       agora-contracts
:CREATED:  [2026-05-23 Sat]
:END:
#+title: Smart Contracts and Contract Marketplace
#+filetags: :passepartout:social-protocol:contracts:revenue:smart-contracts:

The social protocol'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 the social protocol's approach is structurally stronger than existing platforms.

* Why Social Protocol Contracts Are Different

Existing smart contract platforms (Ethereum, Solana, Cosmos) verify only that execution followed the rules. The social protocol'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)
- Social Protocol: The contract is correct with respect to its specification, AND it ran correctly (correctness + execution)

This means social protocol contracts can encode real-world regulations ([[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]], [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]], [[id:513d5996-4ac7-4567-a992-18fc01599104][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 [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], deployment fee per verified contract, premium for certification weight.

Comparison: Ethereum collects ~$20B/yr in transaction fees. The social protocol'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 Passepartout 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 [[id:c9830152-0160-4bdc-ab03-6f308ad43536][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

The social protocol'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 [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][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 [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][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

[[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][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 social protocol instances disagree on a contract execution, submit to a verified arbitrator. The arbitrator runs the contract in their own [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][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 | [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Environment subsystem]] 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 social protocol 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

Passepartout'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 [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]].

* References

- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol overview]]
- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium username registry]]
- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]]
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams overview]]
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The [[id:90484f4a-5b70-4001-93d6-e610e54ed573][Social Protocol Exchange requirements]] specify the contract and exchange layer in detail. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]]]
