Wallets and authority
Four steps stand between an X account and a funded agent wallet. Each one narrows what the agent is allowed to do — none of them widens it.
The four steps
Onboarding is deliberately boring. Nothing here is novel cryptography; the value is in the ordering and in what each signature does not grant.
| # | Step | What it establishes |
|---|---|---|
| 1 | Sign in with X | Which account is talking. Resolves to an immutable numeric account id, never to a handle. |
| 2 | Prove wallet ownership | A signed EIP-4361 (SIWE) message binds a wallet you control to that account id. |
| 3 | Authorize the policy | A signed EIP-712 typed-data grant naming exactly one callable method and the spend caps. |
| 4 | Fund | Value moves to the derived address. Until this point nothing is at stake. |
Step two and step three are separate on purpose. Ownership is a fact about a key; authorization is a policy about behaviour. Proving you hold a wallet grants the agent nothing at all — the grant in step three is the only thing that does, and it is scoped, capped, and revocable.
Deterministic derivation
Every X account carries an immutable numeric id that survives handle changes, display-name changes and profile rebuilds. Almeru maps that id to exactly one agent wallet address, deterministically. One id, one address, permanently.
Because the mapping is a pure function of the id, the address is derivable before it exists. You can compute it, display it, verify it against a third-party calculation, and send funds to it before any contract has been deployed at that address. Deployment is an implementation detail that happens on first use; the destination was already fixed.
x_user_id 1596180932847104000
↓ deterministic derivation (chain 4663)
address 0x2ea9c4b7f18d3056a9c7e21b40fd7c85ba36d0f1
├─ derivable before deployment ✓
├─ changes if handle changes ✗
└─ changes if root owner rotates ✗Root owner and recovery
The wallet you signed with in step two becomes the root owner of the derived wallet. It is the top of the authority chain and it is also the recovery path: if you lose access to the X account, the root owner still controls the wallet; if you lose the root owner key, you rotate it from the X account after re-proving identity.
Rotating the root owner does not change the derived address. Derivation reads the account id and nothing else. This is what makes the address safe to publish, print on a receipt, or hard-code in a payout script — ownership underneath it can change without the destination moving.
What the agent signer may do
The agent holds a signer on your wallet with a single permission: it may call executeLaunch. Nothing else is permitted. It cannot transfer, cannot approve a spender, cannot upgrade an implementation, cannot add or remove signers, and cannot call executeLaunch with parameters that exceed the caps you signed in step three.
| Action | Root owner | Agent signer |
|---|---|---|
| Fund the wallet | Yes | No |
Call executeLaunch | Yes | Yes, within caps |
| Transfer value out | Yes | No |
| Approve a token spender | Yes | No |
| Rotate the root owner | Yes | No |
| Revoke the agent signer | Yes | No |
| Change the derived address | No | No |
Read the last row carefully: the derived address is not an administrable parameter. No key on the system, yours included, can point an account id at a different wallet.
Caps and revocation
The EIP-712 grant carries two ceilings — a per-launch cap and a rolling 24-hour cap. Both are enforced in the contract at call time, not by the service that prepares the call, so a compromised backend still cannot spend past them. Lower them at any time by signing a fresh grant; the newest grant supersedes the previous one.
Revocation is unilateral and immediate. The root owner removes the agent signer in one transaction, after which executeLaunch reverts for the agent while every owner-side action keeps working exactly as before. Funds never move as part of revocation — a revoked wallet is a normal wallet you control.