Launching today
delegare
Give AI agents spending power without giving up control
24 followers
Give AI agents spending power without giving up control
24 followers
Give AI agents real spending power — without giving up control. Delegare lets you define strict spending rules (limits, merchants, expiry), so agents can execute payments safely within those constraints. No card details, prefunded wallets, or private keys shared with the agent. Works for API payments (402/x402), SaaS, and agent workflows. Adds an authorization layer on top of x402. Pricing: 3% (max $0.03 per tx). Minimum $0.005 — includes gas on Base.
@tobiaspfuetze the sending rules model makes sense for single-agent setups. Curious how it works in chains though, if agent A spawns agent B to handle a subtask, does B inherit a A's constraints, or does ech agent need its own delegare scope? that is usually where budget enforcement falls apart in practice..
@cremer yeah that's exactly where most budget systems quietly break.
Delegare rules out the worst failure mode by construction: session keys can't be inherited. Each mandate has a dedicated ERC-4337 session key, KMS-encrypted with context bound to the mandateId — there's literally no signing credential to hand downstream. So the "agent A passes its keys to agent B" footgun is structurally impossible.
What A can pass is the intent mandate itself (a scoped VC — merchant, limit, TTL). Two patterns:
Share the same mandate. A hands B the same mandate and they both call /charge against it. The DynamoDB atomic counter enforces the limit server-side, so concurrent A + B requests can't race past it. No coordination between agents, no double-spend.
Sub-scope separately. If you want B to only spend $2 of A's $10, today that means the user (not A) mints a second mandate scoped tighter — both draw from the user's wallet independently. Native sub-delegation (a child mandate that atomically draws from the parent's counter) is the natural next step; not in the launch build.
Either way the invariant holds: every spend goes through a server-side atomic check on one specific mandate. Agent topology doesn't change the enforcement surface — it's always one atomic op per charge.
@tobiaspfuetze the "user mints a child mandate" requirement for sub-scoping is the interesting constraint... in fully autonomous workflow that is a human-in-the-loop step, which breaks the autonomy.
Is native sub-delegation blocked by something fundamental on the ERC-4337 side or is it mostly engineering time?
@cremer great questions! Short answer: not fundamentally blocked. engineering cost plus an open design question.
The ERC-4337 piece is actually the 'easy' part. Session keys are wallet-module policy — you can design a module where a parent key signs an attestation binding a child key to tighter scope, and the child's UserOps validate against the chain. AP2's SD-JWT-VC intent mandates already support re-issuance with narrowed claims + chain-of-custody proofs, so at the credential layer the primitive exists. EIP-7702 makes this cleaner on the EVM side too.
What's actually hard:
multi-node atomic spend tracking. flat mandates are one dynamodb atomic op per charge. a tree means a child charge draws from both the child's counter and every ancestor's atomically — doable with dynamodb transactions, but the latency and failure-mode surface grows per hop.
graph-wide revocation. revoking the root has to invalidate every descendant before the next /charge — needs a fast lookup path, not just a flag on one row.
on-chain chain verification. the router currently validates one key per tx. validating "this key is a valid descendant of a user-approved mandate with all intermediate caveats respected" is either gas-expensive on-chain, or moves off-chain into the vault and changes the trust model.
On the autonomy point: if A→B→C→D each infers sub-scope from prompts, one prompt injection three levels deep seems catastrophic. The answer probably isn't "remove the human entirely in payment flows". I think it's pre-declared caveats at root mint time.
User authorizes "this mandate can sub-delegate up to e.g. 2 levels and merchants must stay in allowlist.
Agents then mint sub-mandates autonomously within those rules. human sets the shape of the tree at auth time; agents fill it in at runtime.
That's where i suspect we land, but genuinely curious if you've seen a cleaner model.