Reputation & trust.

Standing on Adunai is a set of verifiable claims the user carries with their DID, not a score a platform computes about them. Nothing in it is readable without the subject's signed grant. The grant is the gate, not the caller.

A record you carry, not a score you are given

Most reputation online is a platform asset. The marketplace owns your seller rating; the gig app owns your driver history; leaving means starting from zero. Adunai inverts the ownership. Vouches, attestations, and counterparty signals key to the user's DID, live on open contracts, and move with the user across every application built on the substrateincluding between competing wallets and builders. The Charter binds the Foundation to that portability: no builder receives privileged access at the protocol layer, the Foundation holds no equity in any builder, and no new surface may block a user's ability to leave with their history intact.

Two things the protocol deliberately does not do. It computes no score, the substrate exports verifiable claims, and each reader's own risk engine decides what they add up to. A protocol-issued creditworthiness number would be a fairness and regulatory liability the substrate must not assume. And it publishes nothing by default, every read of reputation data passes through a consent grant the subject signed via SelectiveDisclosure.

Where standing comes from

Reputation is assembled from primitives that each do one thing. All are live on Base Sepolia testnet (full contract registry):

Contract	What it records	Who writes it
AttestationsRegistry	Typed, signed claims, phone verified, employment, legal entity, transaction-history months.	Accredited attesters, via AttesterRegistry
IdentityAttestations	Identity-scoped attestation records with per-DID freshness.	Accredited attesters, benign records require the subject's consent; regulatory and adverse records (AML, sanctions, defaults) are issued without it, by design
VouchingRegistry	Peer vouches, one DID standing behind another. Revocable; an anti-Sybil and trust signal.	Any DID
AgentReputation	Standing for cash-in / cash-out agents on the agent network.	The settlement and dispute contracts, role-gated (granted in Phase 2)
ComplaintRegistry	Dispute intake, anchored to specific agent settlements.	Settlement counterparties

Attestations are the raw material: the claim's hash sits on-chain, the payload stays off-chain, and reads are consent-gated. Payments- and savings-derived reputation fields are a Phase 1+ extension; the v1 catalog is attestation-derived only.

ReputationExport, the portable bundle

ReputationExport is the read-only assembler that turns scattered claims into one artifact a third party can act on. Every function is a view, it mutates nothing and persists nothing. Given a subject DID and a reader, it walks both attestation registries, checks the subject's DID liveness against IdentityRegistry and RevocationRegistryand emits a ReputationBundle: a snapshot stamped with producedAtbound to the specific reader it was produced for, and capped at 64 items.

Consent is fully delegated to SelectiveDisclosure. Bundle production is permissionless, anyone can call it, because the grant, not the caller, is what unlocks each item. An item the subject has not granted to this reader is skipped and counted in omittedCount: the reader sees how much was withheld, never what. A bundle handed to a different reader is detectable by the reader binding. Non-expiring attestations carry a 180-day advisory staleness window: advisory only; the protocol enforces no window.

The reader verifies; the protocol does not rank

A bundle is an honest trust artifact, not an authority. Its value is assembling the verification chain into one manifest, for high-stakes decisions, the reader walks the chain item-by-item against the deployed contracts:

1. Consent. Re-call SelectiveDisclosure.verifyGrantForReadthe subject provably authorized this reader to see this item. The reader re-derives the verdict; it does not trust the bundle's flag.
2. Authenticity. Re-read the attestation from its registry; fetch the off-chain payload and hash-check it against the on-chain dataHash.
3. Freshness. Apply its own staleness policy to producedAt and the per-item verdict.
4. Liveness. Confirm the subject's DID is not revoked.

Each reader sets its own tolerance. The design targets three consumers:

Reader	Decision	Typical posture
Lender	Extend credit	Re-verify item-by-item for large or unsecured loans; accept a fresh snapshot for small, secured ones.
Landlord	Grant a tenancy	A recent snapshot usually suffices; re-verify for high-value leases.
Visa consultant	Recommend or process an application	Always re-verify, the consequences are severe and irreversible.

One deliberate boundary: adversarial schemas (defaults, dispute history, counterparty claims) are excluded from the auto-enumerated push bundle. A user does not push "I defaulted" by default; a lender wanting those signals negotiates a specific single-attestation grant, and the subject consents or does not. The user-controlled surface is non-self-incriminating by design.

Standing on the agent network

AgentReputation and ComplaintRegistry extend the same discipline to the cash-in / cash-out agent economy. Complaints anchor to specific settlements, no free-floating accusations, and agent standing accumulates against a DID, not against any single builder's platform. Both are deployed with the rest of the v1 surface; the settlement rails ship dormant until timelock-governed arming, and the payment-routing whitelist arms through the 14-day timelock.

Tooling and what comes next

The SDK is in-repo today (@adunai/sdkApache-2.0; npm publication lands with the Phase 1 public release). Phase 1+ SDK work adds a bundle parser, a chain re-verifier, and a staleness-policy helper for consumers. Grant management is a wallet-layer concern, see the reference-wallet design preview for how a subject reviews and revokes grants, and Sign in with Adunai for the authentication side of user-controlled access. The reputation model itself is specified in the whitepaper.