About Open Trust
Open Trust is the first platform for creating trust graphs intended for multi-app interoperability in governance use cases. It is built by Agora, and it is in alpha.
What it is
A trust graph is a set of addresses, a set of vouches between them, and a rule for turning those vouches into a weight. Every governance system builds one eventually — a delegate registry, a contributor allowlist, a grant reviewer pool — and almost all of them build it privately, in a table only that application can read.
That is the part worth changing. A graph declared here publishes its rules as an EAS attestation: which addresses trust originates from, which scoring algorithm applies, what its parameters are, who is allowed to vouch and where. Those rules are fixed at the moment of declaration. This platform holds a projection of that attestation so it can be queried quickly, and a database trigger stops the projection from drifting — but the attestation is the graph, and it does not belong to us.
The consequence is the whole point: any application can resolve the same declaration and compute the same answer. Trust earned in one place is legible in another, without an integration, a bilateral agreement, or a request to us.
Alpha, stated plainly
Alpha here means the parts below are real and running, and the parts after them are not. Nothing on this page is a projection.
Works end to end
- Declaring a graph as an offchain EAS attestation, signed in the browser
- Vouching and withdrawing, with every rule enforced identically for the UI and the API
- Roots: genesis sets, and later changes by existing roots where the graph allows it
- Both scoring algorithms — hop decay and EigenTrust — with byte-identical results across runs
- The graph explorer, including path tracing and per-voucher attribution
- The REST API, API keys, scopes and rate limits, documented in OpenAPI 3.1
- Onchain declarations and root changes: built, and simulated on Sepolia
Not built yet
- Ad-hoc scoring parameters
A graph is scored under the parameters frozen in its declaration. Asking the API for “the same graph with a steeper decay” is designed and tested but not yet exposed on any endpoint.
- An /explain endpoint
The explorer traces why an address scores what it scores. That reasoning is computed server-side for the visualization only — an API caller cannot ask for it yet.
- Identity beyond Ethereum addresses
ENS and other name services, and social handles, are reserved in the declaration format and rejected at declaration time. Nothing resolves them yet.
- Onchain vouching in anger
The calldata path is written and unit-tested, and onchain declarations have been simulated on Sepolia. Vouching onchain has not been exercised against a live chain.
One thing alpha does not mean: that a graph you declare now might be rewritten later. A declaration is an attestation, and it is as permanent as anything here gets. That is the reason the wizard makes you review before you sign.
Chains
Open Trust targets Sepolia, Ethereum and Base. The EAS schema UIDs are derived from the schema strings, so they are identical on every chain — a graph is never stranded by the chain it was declared on. What differs is whether this deployment indexes a chain, which is what decides whether a declaration made there will actually appear.
0xC2679fBD37d54388Ce493F1DB75320D236e1815e0xA1207F3BBa224E2c9c3c6D5aF63D0eb1582Ce5870x4200000000000000000000000000000000000021An offchain graph still names a chain, and that is not incidental: the signature's EIP-712 domain binds it to that chain's EAS contract, which is what stops the identical signature counting as a vouch everywhere at once.
The strategy
Four things, in the order they have to happen.
- 01
Iterate on standards & API
A trust graph is only interoperable if two applications reading the same declaration reach the same numbers. That is a specification problem before it is a software one: the three EAS schemas, the canonical encoding of the parameters, the ordering rules that make a fold deterministic. All of it is public, and all of it is still moving.
Status — In progress. The schemas are frozen by their UIDs; the API around them is not.
Read the API reference - 02
Partner with as many organizations as possible
A trust graph with one consumer is a database with extra steps. The value shows up on the second application — when a delegate vetted in one governance system arrives already carrying that standing somewhere else. That needs organizations willing to declare graphs in public and to read each other's.
Status — Open. If you run a governance system and this sounds useful, we want to hear from you. E-mail jeff@voteagora.com
- 03
Finalize licensing & governance
Who governs a shared trust standard, and under what licence, is unresolved. It has to be, at this stage — committing to an answer before there are partners would mean choosing on their behalf. The uncomfortable version: today this platform is run by one company, and the only real protection against that is that the rules live in attestations we cannot edit rather than in a database we can.
Status — Unresolved, deliberately. Stated here rather than left to be discovered.
- 04
Improve trust & governance solutions across Web3
The point of the other three. Sybil resistance, delegate discovery, grant review, contributor recognition — these are all the same shape of problem, and every project currently solves it alone and from scratch. Shared, verifiable trust graphs are the piece that would let them stop.
Status — The destination.
Built by Agora
Agora builds governance infrastructure for protocols including Optimism, ENS, Uniswap and Scroll. Open Trust is the piece those systems kept needing and kept building separately.