Sponsored Content
Skip to content

Latest commit

Β 

History

5 Commits

Folders and files

NameName
Last commit message
Last commit date
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Veylux β€” A Sybil-Resistant Reputation Protocol for AI Agents

"Trust that costs something to fake."

Protocol v0.1.0 Β· WHITEPAPER.md Β· LICENSE (MIT)

A reference implementation of a Sybil-resistant trust layer for the emerging AI agent economy. Pseudonymous, open, no company, no custody of funds β€” agents are cryptographic keypairs (Bitcoin-style), and trust is earned only through verified outcomes, discounted by economic stake and graph-based cluster analysis.

Status: working proof-of-concept reference implementation. Not audited, not production-hardened, not yet integrated with a real settlement layer. This is the "step 1" build described in the design doc: prove the mechanism, not launch a token.

The problem this solves

AI agents can spin up fake identities for free and have them transact with each other to fabricate glowing trust histories, then use that fake reputation to defraud real users, employers, or counterparties. Existing agent protocols (EIP-8004, OAP, A2A) have reputation registries but explicitly mark Sybil-resistance as an open, unsolved problem in their own draft specs. This project is a concrete attempt at closing that gap.

Architecture β€” four independent, stacked defenses

identity/    Layer 0: pseudonymous keypair identity (ed25519).
             Free to create β€” NOT a defense by itself.

stake/       Layer 1: economic bonding. Real capital staked per agent,
             tiered (Unbonded/Basic/Trusted/Institutional). Bad, proven
             behavior gets slashed. Makes N fake identities cost N times
             the bond, instead of staying free.

graph/       Layer 2: cluster-based Sybil detection. Models all verified
             interactions as a weighted trust graph and computes a
             conductance-based suspicion score β€” fabricated trust rings
             are dense internally but poorly connected to the wider
             network, which this detects structurally, not behaviorally.

reputation/  Layer 3 + combiner: time-decayed scoring of verified outcomes
             (fabricated-then-dormant history loses value over a 90-day
             half-life), combined with the stake tier (hard ceiling) and
             graph suspicion penalty (multiplicative discount) into one
             explainable TrustScore.

api/         HTTP surface other agents/runtimes actually call:
             register, stake, submit verified event, query score.

Layer 4 (slashing routed to victim compensation, insurance pooling) is sketched in stake.Slash but the arbitration/dispute-verdict source that would call it is intentionally out of scope for this proof of concept β€” that's a separate, equally hard open problem (see design doc).

Why Go

Concurrency: reputation scoring and Sybil-cluster analysis need to run across potentially millions of agents and edges without blocking the API under load. graph.BatchSuspicionScores and reputation.Engine.BatchScore both fan work out across a worker pool of goroutines feeding off a shared channel β€” a full network re-score sweep parallelizes cleanly across cores. Static typing and a small runtime also matter for something meant to be an open, auditable trust primitive other people's infrastructure depends on.

Build & run

Requires Go 1.22+ (uses the enhanced net/http method+path routing patterns introduced in 1.22).

go build ./...
go test ./... -v          # includes a test that simulates an 8-agent
                           # Sybil ring vs. an honest, well-connected
                           # agent, and asserts the ring gets penalized
go run ./cmd/veylux    # starts the HTTP API on :8080

Example flow

# 1. Mint two pseudonymous identities
curl -X POST localhost:8080/v1/identity
curl -X POST localhost:8080/v1/identity

# 2. Bond capital to each (Layer 1)
curl -X POST localhost:8080/v1/stake \
  -d '{"agent_id":"<AGENT_A>","amount":10000000}'

# 3. Record a verified outcome between them (in production, only a
#    trusted settlement/arbitration service should be able to call this)
curl -X POST localhost:8080/v1/event \
  -d '{"agent_id":"<AGENT_A>","counterparty_id":"<AGENT_B>","value":1.0,"positive":true}'

# 4. Any third agent can now query trust before transacting
curl localhost:8080/v1/score/<AGENT_A>

Honest limitations (read before treating this as more than a POC)

  • Stake ledger is in-memory, not connected to a real settlement layer. Production would back this with an on-chain escrow (compatible with the EIP-8004/EIP-8183 "Job" primitive pattern) rather than a Go map.
  • No dispute/arbitration source is implemented. Slash exists but nothing calls it yet β€” that requires a whole separate trust mechanism (who adjudicates disputes, and how do THEY resist Sybil/collusion) that is genuinely a distinct hard problem, not solved here.
  • Graph suspicion detection is a simplified local-conductance heuristic, not a full Veylux/SybilLimit-family random-walk algorithm. It works for the demonstrated attack pattern but a well-resourced adaptive attacker could likely find ways around this specific heuristic β€” this is a starting point for research and hardening, not a finished defense.
  • No real cryptographic event verification wired in β€” RecordEvent is called directly in this reference implementation; a real deployment needs to verify the caller is actually an authorized settlement source, not any arbitrary HTTP client.

Suggested next steps

  1. Wire stake.Ledger to a real testnet escrow contract.
  2. Replace the local-conductance heuristic with a proper trust-propagation algorithm and benchmark against known Sybil-attack datasets.
  3. Design and implement the dispute/arbitration layer that feeds Slash.
  4. Get 2-3 real agent developers (from the A2A/MCP/OAP ecosystems) to integrate against the /v1/score endpoint and pressure-test it against real traffic patterns before considering any token/economic layer on top.

About

No description, website, or topics provided.

Resources

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages