feat(starknet): session-key spending policies for AI agents
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- python
- Ambito
- blockchain
Direzione di ricerca
Start by reading issue #2 and the agent configuration and funding paths named here: ai_agent_service._execute_funding and agent/cost_guard.py. Verify the current session-key standard, maintained Python client API, and testnet paymaster availability before choosing an account implementation. Done means policy limits are enforced on-chain, session keys can be revoked and expire, and policy parameters map to existing agent config fields, with tests and documentation.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
Enforce AI agent spending limits in a Starknet smart account via session keys, so caps hold even if the backend is compromised, and offer gasless onboarding through a paymaster.
Motivation
Agent budgets (max_per_proposal, daily_budget) are enforced only in application code. On-chain policy is a stronger guarantee and a good showcase of account abstraction.
Current state in this repo
- Limits live in agent config documents and
ai_agent_service._execute_funding;agent/cost_guard.pyenforces a separate set of budgets for the workspace agent.
Proposal
- Register Starknet testnet in the registry (#2) with a minimal adapter.
- Select an account implementation supporting session keys and define a policy (allowed targets/tokens, per-call and per-day limits, expiry).
- Create the session key for an agent and use it for agent-initiated funding calls; revoke on demand from the UI.
- Optionally sponsor fees with a paymaster for new users.
- Document the toolchain (Cairo, Python client) and its cost for contributors.
Acceptance criteria
- An agent can transact within policy and is rejected on-chain beyond it.
- Session keys can be revoked and expire automatically.
- Policy parameters map to the existing agent config fields.
Out of scope
- Proving the quantum simulation with STARKs (research-grade).
- Mainnet.
Technical notes and risks
- Session-key standards are still a draft and wallet implementations are not mutually compatible. Pick one implementation and document the lock-in.
Dependencies
- #2
Verify before implementing
- Current session-key standard status and the maintained Python client API.
- Paymaster availability on testnet.
Part of ##1. Ground rules for all issues in this roadmap are listed there (testnet-first, no secrets in the repo, chain logic behind the registry, tests and docs with every PR).
- Lingua principale
- Python
- Stelle
- 2
- Fork
- 4
- Merge medio
- 5h 19m
- PR unite (30g)
- 11
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di QMeshPy/distributed-quantum
-
enhancement good first issue helia storage tier-1
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
QMeshPy/distributed-quantum#53 ·
I maintainer di solito rispondono entro 1 giorno
-
chain-integration enhancement payments research-spike tier-2
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
QMeshPy/distributed-quantum#78 ·
I maintainer di solito rispondono entro 1 giorno
-
chain-integration enhancement payments research-spike tier-2
Difficoltà 3/5 1-2 giorni Idoneità per principianti 66/100
QMeshPy/distributed-quantum#77 ·
I maintainer di solito rispondono entro 1 giorno
-
chain-integration enhancement payments tier-2
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
QMeshPy/distributed-quantum#76 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation good first issue kubo storage tier-1
Difficoltà 2/5 1-3 ore Idoneità per principianti 42/100
QMeshPy/distributed-quantum#75 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di QMeshPy/distributed-quantum
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
foxglove/mcap#1907 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
namespace operations
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
EclipseFdn/open-vsx.org#14623 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
developmentseed/titiler-cmr#261 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
andrewyng/openworker#774 ·
I maintainer di solito rispondono entro 1 giorno
-
aggfuncAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
worldbank/blackmarblepy#160 ·