A lockfile for
agent money.
Bind every fund-moving call to the exact skill version its owner approved. When the bytes change underneath it, the call reverts inside the settling transaction — before value moves, not after.
Exploring skips the setup steps. Nothing is gated, and you can build a profile later from Account.
EIP-7702 · enforced at · backed by publisher
0x9b68b339278fd5f40079090a0a535d6c687aaacbb36d9ef888a942a12c600b80
Matched for the first 3 characters, then diverges.
0x960ea319b251ab8699fb8fa916c6e27e17ddc1938df41065a63c2227229bb4da
Same name. Same version string. Different code.
Transaction reverted · NOT_PINNED
0 AUSD moved. No bond was slashed — that requires proving the publisher signed two different byte sets under one version string.
Reading
Reading the registry
Reading the registry now. The figures below are placeholders until it answers, and they will be replaced rather than adjusted.
CURRENT BLOCK
…
LIVE PINS
2
BOND LOCKED
1275 AUSD
TOTAL SLASHED
1625 AUSD
| SKILL | VERSION | PUBLISHER | BOND | STATUS |
|---|---|---|---|---|
| kuru-quote | 1.0.0 | 0xf39F…2266 | 125 AUSD | bonded |
| helix-lend | 2.4.1 | 0x7099…79C8 | 1175 AUSD | bonded |
| kuru-quote | 0.9.0 | 0xf39F…2266 | 125 AUSD | revoked |
| swiftswap | 1.2.0 | 0x3C44…93BC | 1675 AUSD | slashed |
THE MECHANISM
Three steps, and only one of them is ours
The publisher acts, the account owner approves, and the guard does arithmetic. Nothing in the middle needs to be trusted, which is the only reason the last step can be relied on.
Publisher ships a version
Publishing hashes the skill directory and locks a bond priced by what that version declared it may do — blast radius, not market value.
publish(skillHash, capabilities)
→ bond locked
The guard compares two hashes
An EIP-7702 delegation points the account at LockstepGuard. It reads the hash pinned in the registry and the hash the call handed over. It never reads the code, so there is nothing in it to argue with.
liveSkillHash(pinId)
== attestedSkillHash
It settles, or it does not
Equal hashes and the call proceeds. Different hashes and it reverts in the same transaction, before value moves. No event is emitted on refusal, because a log written before a revert is rolled back.
✓ SkillExecuted
✗ revert NOT_PINNED
$ npx @lockstep/cli hash ./your-skill
$ npx @lockstep/cli publish ./your-skill
$ npx @lockstep/cli approve ./your-skillApproving runs locally by design. An approval commits to exact bytes, and only the machine holding those bytes can make that claim honestly — a web page asking you to sign a hash it fetched is the shape of the attack this exists to stop.
Where to next
Point it at your own account
Connecting tells the dashboard whose approvals and whose enforcement to read. Everything above works without it — the numbers just belong to somebody else.
No signature is requested and nothing is sent anywhere. The address stays in this browser, because this is a static site with no server behind it. No wallet is detected here, so nothing will prompt you.
SECTION 06Security boundaries & threat model
Four things this does not stop, stated plainly. A security tool that only lists what it catches is asking to be taken on trust.
A stolen key signing an approved version
An attacker holding the executor key who calls the approved skill within its declared capabilities is making a valid call, and it settles. This binds a call to a code version; it is not a second factor on the key.
A skill that was hostile from its first publish
The mechanism catches bytes changing under a version you already approved. A publisher who was malicious before you ever looked at them never drifts, so nothing here fires. What remains is the bond and the capability diff you read before approving.
Which code asked, cryptographically
That part is attested by the runtime, not proven. A compromised runtime can report an honest hash while executing something else, and no signature fixes it because the key is reachable by the compromised process. Closing it needs a TEE. Until then the guarantee is economic: a false claim is provable fraud against a bond.
Anything that does not move funds
Leaked secrets, deleted files, a poisoned reply. This bounds financial blast radius at settlement and is not a general agent sandbox. Indirect prompt injection from content an agent reads is out of scope too.
The honest split is that calldata constraints are cryptographic — target, selector and value ceiling are checked from the transaction itself, whatever anyone claims — while code identity is economic: a false claim about which bytes asked is provable fraud against a bond. Any project asserting otherwise without a TEE in the diagram is overclaiming, and one follow-up question exposes it.
PROBABLY NOT FOR YOU IF
- Your agent does not move funds. There is nothing here to bind.
- You need to stop a compromised key rather than compromised code. Use a spending limit.
- Your account is a contract rather than an EOA. EIP-7702 delegation needs a private key, so it cannot carry a guard.