Proportionality
The proportionality principle -- scaled trust for scaled stakes, from micropayments to multi-million dollar agreements.
The white paper's core implementation principle:
"Trust in depth does not mean maximum assurance at every layer for every interaction. The level of trust must be proportional to the stakes of the transaction."
A $0.001 API call and a $5M supply chain contract do not need the same trust infrastructure. The Agent Legal Context protocol enables proportional deployment by defining three tiers that can be independently adopted.
The eIDAS Analogy
The European eIDAS Regulation defines three levels of electronic signatures: Simple, Advanced, and Qualified. Each provides more assurance, more cost, and more legal weight. The ALC protocol applies the same graduated model across the full identity and legal stack, not just signatures.
| eIDAS Level | ALC Tier | Assurance | Use Case |
|---|---|---|---|
| Simple | Tier 1 (Implicit) | Basic identity, terms available | Micropayments, API calls |
| Advanced | Tier 2 (Explicit) | Verified identity, signed acceptance | SaaS agreements, data licenses |
| Qualified | Tier 3 (Negotiated) | Full verification, mutual signatures, scoped authority | Enterprise contracts, financial settlements |
Proportionality in Practice
| Transaction Example | Tier | Assurance Level | What Is Required |
|---|---|---|---|
| AI agent calls a $0.001 API via MPP | Tier 1 | Low | Wallet address + payment KYC. contentHash in memo. |
| AI agent accepts SaaS SLA for $10K/year | Tier 2 | Medium | Verified human + entity attestation + EIP-712 signed terms |
| AI agents negotiate $5M supply chain contract | Tier 3 | High | Verified humans + entities + negotiation history + mutual signatures + dispute resolver + terms policies |
| AI agents negotiate cross-border financial settlement | Tier 3+ | Maximum | All of the above + jurisdictional establishment + regulatory compliance attestation |
Why Proportionality Matters
Without proportionality, the protocol becomes one of two things:
Too heavy for micropayments. If every API call required EIP-712 signatures, identity verification, and on-chain acceptance records, the overhead would exceed the transaction value. No one would adopt it.
Too light for enterprise contracts. If the protocol only supported implicit acceptance via payment memos, it would be useless for $5M agreements that need negotiation, mutual signatures, and dispute resolution.
The three-tier model avoids both extremes. Vendors choose the tier that matches their transaction value and risk profile. The protocol provides the infrastructure for all three.
The Cost Gradient
| Tier | Per-Transaction Cost | Infrastructure | Proof Strength |
|---|---|---|---|
| Tier 1 | Near-zero (memo field exists) | Terms registry (one tx per terms update) | Time-range: "terms X were in effect when you transacted" |
| Tier 2 | Near-zero (off-chain signature) | Registry + acceptance recording | Per-transaction: "you accepted terms X and paid under them" |
| Tier 3 | Moderate (one-time record creation) | Full IntegraRecord + negotiation history | Complete: parties, terms, history, acceptance, payment binding |
The cost scales with the value. Tier 1 costs nearly nothing per transaction. Tier 3 costs more, but for a $5M contract, the cost of creating an IntegraRecord is negligible relative to the transaction value.
Implementation: Start at Tier 1
Most vendors will start at Tier 1. This requires:
- Create an IntegraRecord for your terms (one-time setup)
- Serve
/.well-known/legal-context.jsonat your domain - Include the contentHash in payment metadata
That is it. No changes to your payment flow. No agent interaction with the ALC API. The terms are bound to every transaction automatically.
As transaction values increase, move to Tier 2 (add acceptanceRequired: true, require EIP-712 signatures). For enterprise-grade agreements, move to Tier 3 (negotiation, mutual signatures, dispute resolvers).
The adoption staircase is described in Getting Started.