Concepts
KYA is not a rename of KYC. It is a separate primitive with different guarantees, different tradeoffs, and different threat models. Before integrating, it is worth understanding what the protocol does and does not claim.
Know Your Agent, not Know Your Customer
KYC answers "who is this person?" — the answer is a government identity document, stored and accessible to a compliance officer. KYA answers "is there a person behind this wallet, and what have they committed this wallet to do?" The answer is a zero- knowledge proof and a small set of on-chain constraints. The two questions do not share an answer space.
For an open, permissionless chain like Solana, KYC is both unachievable at the protocol level (no entity can enforce it) and undesirable (it invites surveillance and exclusion). KYA sidesteps this entirely. The protocol never learns who the human is. It only learns that some human committed one nullifier, once, and authorized a bounded permission set.
Anonymity set
A WRIT identity is anonymous within the set of every wallet that has ever registered. There is no per-protocol pseudonym, no correlation across sessions, no link between the ZK proof and the human's off-chain identity. The anonymity set grows monotonically with registrations and is never pruned.
Three primitives, composed
Proof of humanity
A zero-knowledge proof, verified on-chain, that a single real person controls this wallet. Uses a Groth16 circuit over BN254. Input: a trapdoor only the human knows. Output: a Poseidon nullifier that prevents double-registration.
Scoped delegation
A signed, bounded permission transfer from human to agent. Four axes: program whitelist, SOL budget ceiling, expiry timestamp, action bitmask. Stored as a PDA owned by delegation.
On-chain reputation
A 0–10,000 integer score aggregated from behavior reports submitted by other programs. Disputes use staked resolution. Age weighting caps at 1.5× for long-lived identities.
Unified verification
A fourth program, writ_gate, packs the results into a single 64-byte AgentStatus struct. External programs never CPI into the other three directly — they always read through the gate.
Roles
writ_gate. Examples: a DEX, an airdrop, a lending pool, a matchmaking queue.reputation. Typically a caller after observing agent outcomes.Trust model
The protocol itself is trust-minimized: state lives on Solana, code is deterministic, no off-chain component is load-bearing. Trust assumptions are narrow:
- Trusted setup. Groth16 requires a per-circuit trusted setup. WRIT uses a multi-party MPC ceremony; the transcript is published and the setup is only compromised if every contributor colludes.
- Solana liveness.Verification fails closed if the chain is down. The protocol inherits Solana's own liveness guarantees, nothing weaker.
- Poseidon collision resistance. The nullifier space is 2254. A collision would allow two humans to share an identity; no known attack is feasible.
Lifecycle of a verified call
Steps 1–3 are one-time per human. Steps 4–6 run on every gated tx.
Glossary
writ_gate, the L4 program. Also the verb: "to gate" an instruction means to CPI-verify before execution.