Really clean release. The paper/live parity (kraken paper buy → kraken order buy), the acknowledged=true gate on dangerous tools, cancel-after as a dead-man's switch, and the least-privilege key guidance are the right execution-time controls.
There's one layer those don't cover, and I'm trying to understand how you're thinking about it. The CLI governs what an agent can do at call time, but the agent's authority (who delegated it, scoped to which venues, instruments, position/drawdown limits, expiry) isn't carried in anything verifiable, and there's no independent proof after the fact that a given fill fell within an authorized mandate. Today that's a config flag plus an API key, not a credential.
You already point builders at ERC-8004 for identity/reputation, which is the right call, but 8004's registries are identity/reputation/validation; they don't express principal→agent delegation of trading authority. That's a separate artifact.
We've been building exactly that as an open layer (Observer Protocol: W3C DID + VC, Ed25519, permissionless, resolvable on the DIF Universal Resolver), and it publishes the identity side to 8004 in one click, so it's additive to where you're already sending people. A live, signed trading mandate is fetchable with no account if it's a useful reference:
curl -s https://observerprotocol.org/credentials/maxi-0001-trading-mandate.json
(verify the Ed25519 signature against the did:web DID document, resolve revocation via the status list). Issuance and verification are live; per-trade enforcement is what we're building with design partners.
Genuine roadmap question: do you see verifiable mandate scoping as something the CLI or the MCP server would eventually own, e.g. a --mandate the server checks — or as a layer that lives above any single venue? The answer decides whether this is something to integrate against or stay out of your way on.
Really clean release. The paper/live parity (kraken paper buy → kraken order buy), the acknowledged=true gate on dangerous tools, cancel-after as a dead-man's switch, and the least-privilege key guidance are the right execution-time controls.
There's one layer those don't cover, and I'm trying to understand how you're thinking about it. The CLI governs what an agent can do at call time, but the agent's authority (who delegated it, scoped to which venues, instruments, position/drawdown limits, expiry) isn't carried in anything verifiable, and there's no independent proof after the fact that a given fill fell within an authorized mandate. Today that's a config flag plus an API key, not a credential.
You already point builders at ERC-8004 for identity/reputation, which is the right call, but 8004's registries are identity/reputation/validation; they don't express principal→agent delegation of trading authority. That's a separate artifact.
We've been building exactly that as an open layer (Observer Protocol: W3C DID + VC, Ed25519, permissionless, resolvable on the DIF Universal Resolver), and it publishes the identity side to 8004 in one click, so it's additive to where you're already sending people. A live, signed trading mandate is fetchable with no account if it's a useful reference:
curl -s https://observerprotocol.org/credentials/maxi-0001-trading-mandate.json
(verify the Ed25519 signature against the did:web DID document, resolve revocation via the status list). Issuance and verification are live; per-trade enforcement is what we're building with design partners.
Genuine roadmap question: do you see verifiable mandate scoping as something the CLI or the MCP server would eventually own, e.g. a --mandate the server checks — or as a layer that lives above any single venue? The answer decides whether this is something to integrate against or stay out of your way on.