Security model
The model reads. The chain decides. Everything in this page exists to keep those two sentences true even when something upstream is compromised.
Interpretation is not authority
The one structural claim worth making about Almeru is narrow and testable: the language model can interpret a request, but it cannot create permission to act on one. Parsing produces a typed launch request — an object with a name, a ticker, an amount and an asset. That object is then checked against a grant the model never signed, spent from a wallet the model does not own, through a method the model cannot widen.
The practical consequence is that prompt injection degrades into noise. Text that tells the agent to transfer funds parses into a launch request with no valid fields and is rejected at validation. Text that tells it to raise a cap parses into nothing at all, because caps are not a parser output. The worst outcome of a fully manipulated model is a launch you did not want, priced inside the caps you already signed — bad, bounded, and visible in the reply thread.
Identity controls
| Control | What it prevents |
|---|---|
| Signed webhooks | Forged posts. Every inbound event carries a signature checked before parsing; unsigned or stale deliveries are dropped without reaching the model. |
| Immutable numeric account ids | Handle-squatting and display-name impersonation. Binding is to the numeric id, so renaming an account changes nothing about which wallet it controls. |
| Single-use login nonces | Replay of a captured SIWE signature. Each nonce is issued once, consumed once, and expires on a short window. |
Contract controls
| Control | What it prevents |
|---|---|
| Pinned implementation set | Deploying arbitrary bytecode. Launches can only instantiate implementations from a fixed, published set — the agent chooses among them, never writes one. |
| Atomic-or-revert launches | Half-built protocols. A launch either completes every step in one transaction or leaves no state behind and no funds moved. |
| Simulation one block ahead | Wasted spend on doomed calls. The exact call is dry-run one block before execution; a revert in simulation stops the launch and replies instead. |
| Per-launch and rolling 24-hour caps | Drain-by-repetition. One oversized launch is blocked by the per-launch ceiling; many small ones are blocked by the rolling window. |
What a compromised model could reach
| Scenario | Reachable? | Why |
|---|---|---|
| Launch something you did not ask for | Yes, within caps | Launching is the one action the agent is authorised to perform. |
| Move funds to an arbitrary address | No | The signer may call executeLaunch and nothing else. |
| Raise a cap or change a fee split | No | Both live in the contract and are not parser outputs. |
| Point your account id at another wallet | No | Derivation is a pure function of the immutable id. |
| Deploy unreviewed contract code | No | The implementation set is pinned. |
| Keep acting after revocation | No | Revoking the signer makes the method revert immediately. |
Residual risks
Controls bound the damage; they do not remove it. These four are real and are not engineered away by anything above.
| Risk | Statement |
|---|---|
| Market | Protocol mechanics do not create value. A miner can settle flawlessly and still leave participants down; buybacks funded by the losing side are activity-dependent and stop when activity stops. |
| Contract | Pinning an implementation set narrows the attack surface to that set. A defect inside a pinned implementation is a defect in every protocol deployed from it. |
| Infrastructure | Ingest, parsing and simulation run off chain. An outage stops launches and can strand a round at a phase boundary; a no-draw returns entries, but the interruption is real. |
| Governance | Someone decides what enters the pinned set and what the default caps are. That is a human process with human failure modes, and no signature you make constrains it. |