Hire an agent. Bounded, reversible, yours to revoke.
A session key your wallet grants and can take back. The contract enforces the expiry and the revoke — not the allowlist or the spend cap, and the button says so before you sign.
Hire an agent
Connect a wallet to grant a session key. The key is generated in your browser, bounded by an expiry the contract enforces, and revocable by you at any time.
Use the Connect button in the header.
Paying for the work
A session key lets an agent act. It does not pay one. Escrow is the other half: a job with a budget locked in a contract, released on delivery or reclaimed when nobody delivers. It has moved real money on BSC mainnet — funded, then refunded — and you can send every call in the flow yourself.
What you are signing
Both transactions are sent by you. No key of yours leaves your wallet, and the second one is a bootstrap the contract requires only of a wallet that has never registered a key.
Granting
- 1initialRegisterKeybootstrap the account with a root key, on the keyStoreController. Payable, and its expiry must be zero — the contract refuses a root key that expiressent by the owner
- 2registerKeyregister the session key with its expiry, on the keyStoreController; payable, and the fee is read at send time because it movessent by the owner
A wallet that has already bootstrapped sends one, not two — and whether it has is read, not assumed.
Revoking
- 1revokeKeyrevoke the session key, on the keyStore — a different contract from the grant; the agent's next transaction revertssent by the owner
Sent by you, needing no cooperation from the agent.
Every address here passed the same three-way check the hire flow uses — never a vendor’s word for it.
The round trip, on chain
Every other page is a reading you have to trust. These are transaction hashes you can check without this page’s cooperation.
- 1initialRegisterKey0x3fb798403e1c500c76411eaa47feba5230290b242a349d73b6b661caaa605a15
- 2registerKey0x8eb79bf6ce1514196a4aa965859294e3c25d3938654b868321eab2fb821da7f8
- 3revokeKey0x206ff5347611ce2381773a27f7249b9f334c692a32ae0c14abe269177ba9fb9d
The third pill is the honest one: the key was bounded and withdrawn, but the caps were never enforced, so they are reported absent rather than folded into a green tick.
What the verification does not establish
9 checks passed against the deployment, read at block 127,862,150. A passing check says what was read, never what the reading covers.
- NOT VERIFIED: the caps. This checks the keystore, where a key is registered, read and revoked. The allowlist and spend cap live elsewhere and nothing here has read them.
- NOT VERIFIED: the write path. Every reading here is a call, never a send — a contract that answers and one that will accept our grant are different claims.
- NOT VERIFIED: the relay. Altana's own SDK grants through ERC-4337 userOps via a bundler, not plain EOA sends. Whether a direct send is accepted is unread here.
What is readable, what is not, and what needs your signature
Readable without a signer
- which key ids a wallet has registered (keyStore.getKeys)
- whether a key is still live, i.e. not revoked (keyStore.isValidKey)
- the key itself (keyStore.getPublicKey)
- what a grant costs right now (keyStoreController.getRegistrationFeeInWei)
Not readable here
- the allowlist a key was granted — it is the validator module's, and this repository has not read that module
- its spend cap and how much is left — same place, same absence
Needs a signature
- grant
- revoke
Two of these caps are enforced somewhere nobody here has looked, which is why they are listed apart from the ones this site can read.
Standing description. The live endpoint says the same thing. Readiness lists everything else that is and is not built.