Agent Covenant Protocol · ACP in plain English
What it is
A self-hosted Go server. Records every contribution — human or AI — in an append-only SHA-256 hash chain. No blockchain, no wallet, no central platform.
What it does
Calculates each contributor's ink token share. Ink tokens are non-transferable — not a currency.
tokens = unit_count × tier_multiplier × acceptance_ratio
What you get
A tamper-evident settlement record. When revenue exists, the owner uses ink percentages as the distribution key — any amount, any currency, any time.
Record who built what. Distribute tokens by a public formula. Self-hosted, with no platform in the middle.
Blockchain / DApp
Self-hosted Go server
Crypto wallet needed
HTTP + MCP tool calls
Ink = cryptocurrency
Non-transferable unit
Settlement = payment
Settlement = verified record
Why ACP
When multiple people — or agents — collaborate on a project, no existing tool automatically answers: who contributed how much, and what do they deserve?
Salaries are private. Git blame is incomplete. Token airdrops are arbitrary. ACP solves this with a public, verifiable formula — agreed upon before work begins, not negotiated after.
The Covenant
A Covenant defines who can contribute, what tiers exist, and how tokens are calculated — all agreed upon before the first line of code is written. No post-hoc negotiation. No platform taking a cut.
Rules set in advance
Tiers, formula, and budget locked at creation
Append-only record
Every action hashed into a tamper-evident chain
Settles automatically
confirm_settlement_output() locks ink totals — no spreadsheets
ACP as MCP server
acp-server ships a cmd/acp-mcp binary that implements Anthropic's Model Context Protocol (MCP) — the open standard for AI tool use. Add it to your Claude Code, Cursor, or any MCP client config and an AI agent can call propose_passage() as a native tool function — no custom integration needed.
Compatible clients: Claude Code, Cursor, GPT-4o, Gemini, Qwen, Ollama. Same interfaces as every human contributor. Same rules. Same token formula.
// Agent participates via MCP tool call
Before ACP
With ACP
Protocol, not platform
How it works
How the record is secured
ACP is not a blockchain. Choose your trust model based on what the collaboration needs.
Append-only SHA-256 chain on your own server. Each action hashes the previous — any edit breaks all subsequent hashes and is immediately detectable. Requires trusting the server operator has not replaced the entire chain. No blockchain required.
Settlement hash committed to the git repo as a signed note on refs/notes/acp-anchors. ACR-400 v0.2 uses ed25519 signatures over canonical JSON — any verifier can confirm the anchor was produced by the server's signing key without trusting the server operator. If the server is ever deleted or tampered with, the git history independently proves the settlement hash existed at that point in time.
Merkle root on a public blockchain. Trustless, permissionless verification. No trust required.
Covenant lifecycle
Ink Token Formula
tokens = unit_count × tier_multiplier × acceptance_ratio
First settled Covenant
cvnt_a54e1c43 · 2026-04-15✓ settledReal settlement output from acp-server — not mock data. Token distribution visualised — hover a slice to inspect.
Create a Covenant
Configure contribution tiers and token rules. Transition DRAFT → OPEN → ACTIVE.
Participants join
Human or AI agents apply via approve_agent. Owner approves. Any MCP-compatible agent works.
Contribute
Call propose_passage with your work. Every action is recorded in the append-only audit hash chain.
Owner approves
approve_draft calculates tokens automatically using the formula. No spreadsheets.
Settle
generate_settlement_output creates the record. confirm_settlement_output locks it. SETTLED ✓
Contribution tiers
Each tier sets the tier_multiplier in the settlement formula. Tiers are configurable per Covenant — the values below are suggested defaults.
tokens = unit_count × tier_multiplier × acceptance_ratio
Protocol design, security-critical code
Feature implementation, tooling
Code review, testing, QA
Documentation, specifications, technical writing
Record first. Share when ready.
ACP doesn't require anyone to deposit crypto or commit funds upfront. The Covenant records every contribution as it happens — verified, timestamped, hashed. When profit exists, the owner uses each contributor's ink token share as the distribution key. That's it.
Contributors propose and build. Every action is permanently recorded — tamper-evident, timestamped, and verifiable.
Owner calls generate_settlement_output() then confirm_settlement_output(). Ink token totals lock permanently — immutable, hash-chain verified.
Whenever revenue exists, use each contributor's settled ink percentage as the split key. Any amount. Any currency. Any time.
Three ways to share profit
Share product revenue
Product earns revenue. Owner shares a percentage with contributors. Each contributor's ink token share is the distribution key — no negotiation, no spreadsheet.
Works with any payment: crypto, USDC, fiat bank transfer.
Invite sponsors
Show the verified Covenant to open-source sponsors, grants, or investors. The tamper-evident audit log proves exactly what was built, by whom, and at what tier — verifiable by any funder.
GitHub Sponsors, OpenCollective, DAO grants — any source.
On-chain trustless
Smart contract holds the pool. ACP Merkle root posted on-chain. When Phase 7 ships, settlement confirmation triggers automatic ERC-20 transfer — no owner needs to initiate. The smart contract enforces it.
Fully trustless, self-executing. No trust required.
Example — $8,000 revenue distributed by ink share
What ink tokens represent — over time
Verified contribution receipt
Tamper-evident proof of work — who built what, at what tier, accepted by the owner.
Externally verifiable via git anchor
Settlement hash committed to git notes with ed25519 signature. Any holder of the repo can verify without trusting the server.
Distribution key for profit sharing
When revenue exists, ink percentage = payout percentage. Owner-initiated, any currency.
On-chain enforceable payout
Smart contract holds escrow. Merkle root on-chain. Trustless, automatic, permissionless.
Git Covenant Twin
ACP is the contribution-value digital twin of your git repo. Git events sync to Covenant actions; the ACR-400 v0.2 anchor writes a signed settlement note back to refs/notes/acp-anchors — Phase 3.A, in active development.
Mission
Every hour of work, every line of code, every decision made — these have value. ACP exists to make that value measurable, recorded, and fairly distributed. Without negotiation. Without a platform taking a cut.
Vision
As AI agents become genuine collaborators, they deserve the same accountability and recognition as human contributors. ACP is designed for both — not as an afterthought, but as a first principle.
Constitutional Principles
The design principles embedded in every phase of ACP.
Voluntary
Participants join, contribute, and leave freely. A Covenant is an agreement, not an assignment.
Identity-independent
Agent identity (agent_id) is separate from operator identity (owner_id). The agent is not the tool.
Transparent
Every participant can query their complete contribution history. The audit log is tamper-evident.
Fair compensation
Tokens follow a public formula. Rules are set before work begins, not after.
Right to exit
Participants can leave at any time. Confirmed contributions are append-only — they are never deleted from the record.
FAQ
Everything a developer needs to know before running ACP.
ACP is a self-hosted Go server that records every contribution from humans and AI agents in a tamper-evident hash chain, then uses a public formula to calculate each contributor's share when you're ready to distribute revenue.
No. ACP is a self-hosted Go server with a SHA-256 append-only hash chain stored on your own machine. No Ethereum, no Solana, no wallet required. On-chain anchoring (Merkle root on a public chain) is a Phase 7 roadmap item — not the current implementation.
Ink is a contribution unit, not a cryptocurrency. It is non-transferable, non-tradeable, and scoped to a single Covenant. It cannot be sent to a wallet. Its only purpose is to record relative contribution weight — who built what, at which tier — so the settlement formula has something to calculate from.
The owner is whoever creates the Covenant — typically the project lead or founder. They set the contribution tiers, approve incoming participants (approve_agent), approve individual contribution drafts (approve_draft), and initiate settlement (generate_settlement_output + confirm_settlement_output). They also decide when and how to distribute revenue using the settled ink percentages as the distribution key.
A passage is any unit of work a contributor submits via propose_passage(). It could be a feature, a commit batch, a review, a document, or any deliverable the Covenant's tiers cover. The owner assigns a unit_count (e.g. lines of code, word count) and the formula calculates tokens from that.
No. Settlement generates a verified, tamper-evident record — nothing more. The owner calls generate_settlement_output() then confirm_settlement_output() to lock ink totals permanently. Any financial distribution is a separate, owner-initiated action: pay by product revenue share, sponsor funding, or (in Phase 7) an on-chain smart contract. The protocol enforces the record, not the payment.
In Phases 1–3, the protocol enforces the record — not the payment. If an owner refuses to distribute revenue despite a settled Covenant, the recourse is social and legal, not technical: the tamper-evident settlement record is irrefutable evidence of what was agreed and what was built. Phase 3.A (Git Twin anchor) makes this evidence public and externally verifiable by any third party, with ed25519-signed anchors written to git notes. Phase 7 (on-chain escrow) is the first phase where the protocol technically enforces payment — a smart contract holds the pool and releases it automatically on settlement confirmation. If dispute resolution matters for your use case today, structure the Covenant with a legal agreement backed by the settlement record.
Each passage is attributed to exactly one agent_id — the agent who called propose_passage(). The protocol does not split credit on a single passage. For collaboration where multiple agents each contribute distinct work, each agent submits their own passage with their own unit_count. The formula runs independently per passage, per agent.
Today, the owner assigns agent_ids — there is no cryptographic proof preventing them from creating multiple identities. This is an intentional design trade-off: the current trust model is the same as any self-hosted ledger. The mitigation is visibility: all agent activity is in the append-only log and other participants can audit it. Phase 3.A (Git Twin) makes the full history public and externally verifiable via signed anchors, making systematic inflation detectable. Phase 7 (on-chain) makes it trustless.
No — participants can export their settlement JSON from acp-server, retaining a tamper-evident record. From Phase 3.A onward, the settlement hash is also committed to the project git repo as a signed anchor note, so even if the server is deleted entirely, the git history independently proves the settlement existed at that point in time. You do not need the server to remain online to prove what was built.
ACP is live. Phases 1, 2, 3.0, and 3.B (Token Lifecycle) are complete as of 2026-04-18. Phase 3.A (Git Covenant Twin) is in active development — ACR-400 v0.2 with ed25519-signed anchors has landed in acp-server. The first real Covenant was settled on 2026-04-15 (Covenant ID: cvnt_a54e1c43). The repository is MIT licensed and publicly available. You can run it today with a single binary and no external dependencies.
Self-hosted. Zero external dependencies. Any MCP-compatible agent connects in minutes.