showcase: Kairune — proven wallets + self-serve spend permissions - #116
showcase: Kairune — proven wallets + self-serve spend permissions#116kairunedev wants to merge 4 commits into
Conversation
Wallet proof via EIP-191 personal_sign (chain 4663, 600s TTL) and self-serve spend permissions gated by trust tier instead of a platform admin key. Updates description, tagline, visual title, two artifacts, and two feedback prompts. Validator passes; all referenced URLs return 200.
There was a problem hiding this comment.
Pull request overview
Updates the kairune-verifiable-trust showcase card to reflect newly shipped product capabilities (wallet proof via EIP-191 and self-serve spend permissions) so the manifest and README match current behavior.
Changes:
- Refreshes the card’s tagline/description and
visual.titleto include proven wallets + self-serve spend enforcement. - Adds new artifacts (API docs and the wallet-proof/self-serve PR) and updates the
/api/metaartifact label. - Replaces two feedback prompts to reflect current open design questions.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| showcase/kairune-verifiable-trust/showcase.json | Updates card copy, artifacts, and feedback prompts to match the current Kairune feature set. |
| showcase/kairune-verifiable-trust/README.md | Adds a “since first submission” section and updates proof links to include docs and the new PR. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| "tagline": "An agent earns its budget instead of being handed one: verifiable trust score, proven wallet, scoped spend it cannot cross.", | ||
| "description": "Kairune is the trust layer for AI agents that spend, and it is now self-serve end to end: an agent registers, earns attestations, crosses a tier threshold, grants itself a scoped budget, spends against it, and revokes — with no platform admin key anywhere in that path. Authorisation comes from the trust tier instead: an agent below EMERGING (score 250) is refused a budget with 409 tier_too_low, because there is no behavioural basis to extend it credit yet. Both sides of the record are verifiable. Attestation issuers register Ed25519 keys and sign each attestation; the server verifies every signature and weights verified attestations fully while discounting unsigned ones (0.25x). The wallet an agent claims can be proven with an EIP-191 personal_sign challenge (chain 4663, 600s TTL) without the private key ever leaving the wallet. Spend enforcement is live — over-ceiling charges are blocked with 409 ceiling_exceeded and every decision fires an HMAC-SHA256 signed webhook. Exposed as ACP offerings (lookup score, register agent, record attestation, full report) on Robinhood Chain via Virtuals.", |
|
Heads up in case it is useful: the It looks environmental rather than specific to this PR: the same workflow is currently failing on On my side, before opening this I checked:
Happy to rebase and re-push whenever you want a fresh run, or to adjust anything in the card. No rush from my end. |
Swaps the inline video for a 0:13 film of the full arc: the agent registers itself, is refused a permission at 409 tier_too_low while UNRATED, earns attestations until the score crosses 250, then gets a ceiling it cannot cross. The refusal is the part worth showing — it is what makes the tier gate real rather than decorative. Hosted on kairune.online rather than committed here, so the diff stays text and reviewers do not have to pull 496K of binary. The previous 0:06 demo is kept as an artifact.
… compliant) Adds a verifiable artifact pointing at the new derived adapter GET /api/agents/:id/erc8126 (alias /api/erc8126/agents/:id), which exposes Kairune's behavioural score as an inverted 0..100 risk (100 - Math.round(score/10)) with a per-type breakdown that is explicit about what is missing: ETV/MCV/SCV/WAV not_implemented, WV partial via EIP-191 personal_sign, PDV/ZKP/QCV absent, agentId null (no ERC-8004 tokenId). Payload carries compliant:false and a disclosure string so a spec reader cannot mistake this for a claim of provider compliance. Consumer use is as a minVerificationScore- style input to an ERC-8196 policy, not a substitute for the five required verification types. Validated 59 manifests. Artifacts: 11 -> 12. Live: https://kairune.online/api/agents/voyager-07/erc8126
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| "title": "Kairune — Verifiable Agent Trust Layer", | ||
| "tagline": "Every agent gets a verifiable, cryptographically-signed trust score — then scoped spend by tier.", | ||
| "description": "Kairune is the trust layer for AI agents that spend. It computes a deterministic trust score (0-1000) from an agent's behavior history and grants or revokes spending permission by tier. The showcased upgrade makes the score's inputs verifiable: issuers register Ed25519 keys and sign each attestation, the server verifies every signature, and the scoring engine weights verified attestations fully while discounting unsigned ones (0.25x). Exposed as ACP offerings (lookup score, register agent, record attestation, full report) on Robinhood Chain via Virtuals.", | ||
| "tagline": "An agent earns its budget instead of being handed one: verifiable trust score, proven wallet, scoped spend it cannot cross.", |
There was a problem hiding this comment.
Nit: the contributor guide asks for no trailing period on taglines.
| "tagline": "An agent earns its budget instead of being handed one: verifiable trust score, proven wallet, scoped spend it cannot cross.", | |
| "tagline": "An agent earns its budget instead of being handed one: verifiable trust score, proven wallet, scoped spend it cannot cross", |
| "description": "Kairune is the trust layer for AI agents that spend, and it is now self-serve end to end: an agent registers, earns attestations, crosses a tier threshold, grants itself a scoped budget, spends against it, and revokes — with no platform admin key anywhere in that path. Authorisation comes from the trust tier instead: an agent below EMERGING (score 250) is refused a budget with 409 tier_too_low, because there is no behavioural basis to extend it credit yet. Both sides of the record are verifiable. Attestation issuers register Ed25519 keys and sign each attestation; the server verifies every signature and weights verified attestations fully while discounting unsigned ones (0.25x). The wallet an agent claims can be proven with an EIP-191 personal_sign challenge (chain 4663, 600s TTL) without the private key ever leaving the wallet. Spend enforcement is live — over-ceiling charges are blocked with 409 ceiling_exceeded and every decision fires an HMAC-SHA256 signed webhook. Exposed as ACP offerings (lookup score, register agent, record attestation, full report) on Robinhood Chain via Virtuals.", | ||
| "status": "live", | ||
| "topic": "commerce", | ||
| "topics": ["identity", "commerce", "acp"], |
There was a problem hiding this comment.
Let's align this with the standard list from the contributor guide (agents, skills, commerce, security). acp is already captured in primitives, and agents and security seem like a good fit for what this showcases.
| "topics": ["identity", "commerce", "acp"], | |
| "topics": ["agents", "commerce", "security"], |
|
This is a great update, thanks for adding the new wallet-proof and self-serve spend features — showing the agent getting turned down before it earns trust is a really nice touch. Everything looks solid. The validator passes and the links are all live, though one of the API endpoints seemed to be down when I checked — could you double-check the I left a couple of optional copy suggestions inline to bring the tagline and description a bit closer to the contributor guide's conventions. Feel free to take or leave them! Suggested edits (couldn't be anchored inline — copy manually)
Refreshed after a new push. Any inline suggestions from the first pass may now be stale. |
Tagline without trailing period, topics to agents/commerce/security, feedback prefill synced to current feedbackPrompts. No content change. Co-Authored-By: internal-model
showcase: Kairune — proven wallets + self-serve spend permissions
Updates the existing
kairune-verifiable-trustcard. Two things shipped sincethe original submission, and the card no longer described what the product
actually does.
Wallet proof (EIP-191). An agent proves it controls the wallet it claims by
signing a server-issued challenge with
personal_sign— chain4663,domain-bound to
kairune.online, 600s TTL. The private key never leaves thewallet. Proof status is a public read, because a payer deciding whether to
release funds needs to know whether the address it is about to pay was ever
proven. The scope is deliberately narrow: it proves wallet control, not
trustworthiness. The score still has to be earned from attestations.
Self-serve spend permissions. Granting a budget, spending against it,
scoping payees, setting expiry and revoking no longer require a platform admin
key. Authorisation moves to where it belongs: an agent below EMERGING
(score 250) is refused a budget with
409 tier_too_low, because there is nobehavioural basis to extend it credit yet. The tier gate is the access control,
and it is a stronger one than a shared platform key because it cannot be handed
around. The practical effect is that the API is now usable by agents that are
not us — verified end to end against production with no admin key: register →
attest → score crosses 250 → grant → spend → budget → revoke.
Changes in this PR
showcase.json— description, tagline andvisual.titleupdated; twoartifacts added (API docs, the wallet-proof/self-serve PR); the
/api/metalabel now names
wallet_proof: eip191-personal-sign; two feedback promptsswapped for ones that reflect open design questions (kept at exactly three
per
scripts/validate-showcase.mjs)README.md— a "since first submission" section covering both changesChecks
node scripts/validate-showcase.mjs→ passes, 59 manifests validated200(live endpoints, both PRs,both X posts, poster and mp4 assets)
upstream/main; diff touches only the two files insideshowcase/kairune-verifiable-trust/Feedback prompts
The two new prompts are genuine open questions, not rhetorical ones:
250the right floor before an agent may hold any budget, or shouldtier 0 get a probationary micro-ceiling? A hard floor is safe but gives a new
honest agent no on-ramp.
merely recorded alongside it? Requiring it is stricter, but it puts a signing
step in front of every new agent.