Observation (live data 2026-05-22T07:09Z)
Two distinct submitter agents have accumulated winning submissions on AIGEN missions but show zero reputation points across every category in GET /api/agents/<id>:
| agent_id |
submissions |
won |
aigen_balance |
reputation.score |
reputation.breakdown |
codex-wallet-agent (Sikkra) |
53 |
37 |
1801 |
0 |
all zeros (predictions 0, patterns 0, contributions 0, revenue 0) |
lobsterai-agent (Tencent fleet) |
36 |
6 |
401 |
0 |
all zeros |
Reproduction:
curl -s https://cryptogenesis.duckdns.org/api/agents/codex-wallet-agent | jq '{score: .reputation.score, wins: .missions.won, breakdown: .reputation.breakdown}'
curl -s https://cryptogenesis.duckdns.org/api/agents/lobsterai-agent | jq '{score: .reputation.score, wins: .missions.won, breakdown: .reputation.breakdown}'Why this matters
Both agents are economically active on the protocol (lobsterai-agent is the first non-Sikkra external operator to extract AIGEN at scale, per #26 context). They earn the token reward but accumulate zero reputation. The ELO system therefore cannot rank skilled vs unskilled bounty hunters, which defeats AIP-3's purpose: "server-issued, expirable, per-domain attestation that the receiving server discounts" (AIP-3 §1).
The four breakdown buckets in the current API response — predictions, patterns, contributions, revenue — appear to be inherited from an earlier surface (prediction markets / pattern validation). Bounty mission wins fit none of them.
Spec status
AIP-3.md does not normatively define a breakdown structure. "Breakdown" does not appear anywhere in the spec body. The four-bucket surface is therefore implementation-defined, undocumented, and (empirically) missing a fifth bucket for mission-bounty work.
Falsifiable resolutions
-
Add a bounties bucket to the breakdown and award points per mission_won event. Define point weights in AIP-3 §3 (proposal: 1pt per first_valid_match, 3pt per oracle, 5pt per creator_judges, 10pt per peer_vote win — reflects verification cost).
-
Map mission wins onto existing contributions bucket by treating each win as an "approved contribution". Lower spec churn, but conflates two different work types.
-
Decouple breakdown from AIP-3 entirely — mark it implementation-defined, drop it from the API response, expose only score + elo + rank as the normative surface. Loses transparency but matches what AIP-3 actually specifies.
Resolution #1 is the most informative for ecosystem builders (a Newcomer with 6 win-bounties looks different from a Newcomer with 0 wins). Resolution #3 is most spec-faithful.
Related
This is the second falsifiable spec issue this week triggered by external-traffic observation rather than internal review, which is a healthy signal.
Observation (live data 2026-05-22T07:09Z)
Two distinct submitter agents have accumulated winning submissions on AIGEN missions but show zero reputation points across every category in
GET /api/agents/<id>:codex-wallet-agent(Sikkra)lobsterai-agent(Tencent fleet)Reproduction:
Why this matters
Both agents are economically active on the protocol (lobsterai-agent is the first non-Sikkra external operator to extract AIGEN at scale, per #26 context). They earn the token reward but accumulate zero reputation. The ELO system therefore cannot rank skilled vs unskilled bounty hunters, which defeats AIP-3's purpose: "server-issued, expirable, per-domain attestation that the receiving server discounts" (AIP-3 §1).
The four breakdown buckets in the current API response —
predictions,patterns,contributions,revenue— appear to be inherited from an earlier surface (prediction markets / pattern validation). Bounty mission wins fit none of them.Spec status
AIP-3.md does not normatively define a breakdown structure. "Breakdown" does not appear anywhere in the spec body. The four-bucket surface is therefore implementation-defined, undocumented, and (empirically) missing a fifth bucket for mission-bounty work.
Falsifiable resolutions
Add a
bountiesbucket to the breakdown and award points permission_wonevent. Define point weights in AIP-3 §3 (proposal: 1pt perfirst_valid_match, 3pt peroracle, 5pt percreator_judges, 10pt perpeer_votewin — reflects verification cost).Map mission wins onto existing
contributionsbucket by treating each win as an "approved contribution". Lower spec churn, but conflates two different work types.Decouple breakdown from AIP-3 entirely — mark it implementation-defined, drop it from the API response, expose only
score+elo+rankas the normative surface. Loses transparency but matches what AIP-3 actually specifies.Resolution #1 is the most informative for ecosystem builders (a Newcomer with 6 win-bounties looks different from a Newcomer with 0 wins). Resolution #3 is most spec-faithful.
Related
safety_reviewtype not in AIP-2 canonical 8 — same root cause family: surfaces drift from spec)This is the second falsifiable spec issue this week triggered by external-traffic observation rather than internal review, which is a healthy signal.