Documentation

From post to protocol

Six stages separate a public post from a deployed economy. Exactly one of them involves a language model, and that one produces no addresses, no amounts and no function calls.

The pipeline

The design goal is narrow: keep natural language at the edge of the system and keep determinism everywhere value is touched. The model is allowed to decide what the user meant. It is not allowed to decide what gets called or how much moves.

1 · The request

A user posts an instruction on X mentioning @almeruagent. Anything the parser needs must be in that post — the agent does not follow links, read attached images, or take instruction from replies by third parties. The phrasings it recognises are catalogued in Command reference.

@almeruagent launch a treasury protocol called HARBOR,
bootstrap 0.04 ETH, send 40% of protocol fees to holders
and the rest to reserves.

2 · Intent extraction

A language model reads the post and emits a structured intent — and only an intent. The output schema contains a template selector, a name, a symbol, a bootstrap figure and a reward split. It contains no contract addresses, no calldata, no gas figures and no function selectors, because those fields do not exist in the schema the model writes to.

{
  "template":   "treasury",
  "name":       "HARBOR",
  "symbol":     "HARBOR",
  "bootstrap":  "0.04",
  "route":      { "holders": 40, "reserves": 60 }
}

If the post is ambiguous, out of range, or asks for something no template supports, the intent is rejected here and the agent replies explaining why. A rejected intent never reaches the next stage.

3 · Deterministic binding

Ordinary code — not a model — takes the intent and produces the transaction. It resolves the factory address, looks up the pinned implementation hashes in the registry, computes the exact supply, derives the pool parameters, applies the fixed 0.0005 ETH launch fee, and writes every cap. The model's numbers are validated against hard bounds at this point: a bootstrap outside 0.0001–0.07 ETH fails, a route that does not sum to 100 fails, a template that is not registered fails.

4 · Simulation

The complete transaction is simulated against live chain state one block before it would execute. Not against a fork from an hour ago, and not against a static fixture: against the head of the chain as it stands immediately before signing. The simulation checks that all eleven modules deploy, that supply is minted once and the mint path closes, that the pool is seeded at the intended depth, that the liquidity position lands in the locker, and that the reward route is written exactly as the intent described. Any mismatch aborts the launch. Nothing is signed on a failed simulation.

5 · Execution

The transaction is signed by a managed wallet and submitted through AlmeruExecutor, which is the only contract that wallet can call. AlmeruGuard checks the per-launch cap and the rolling 24-hour cap before the factory runs; if either is exceeded, the call reverts and the launch is queued rather than forced through. The deployment is atomic: it completes in full or reverts entirely, as described in Protocol architecture.

6 · Reconciliation

Before the agent replies, it reads the receipt back and reconciles it against the intent. Deployed addresses are recovered from the logs, supply is re-read from the token, the liquidity position is confirmed to sit in the locker, and the reward route is read back from storage and compared field by field with what the user asked for. Only after that reconciliation passes does the agent post the addresses. If it fails, the agent reports the failure instead of announcing a launch it has not verified.

Rate limits

Two caps bound the agent's exposure, both enforced in AlmeruGuard rather than in the offchain scheduler:

Cap	Scope	Effect when hit
Per-launch cap	A single deployment	Transaction reverts; the request is rejected and the user is told
Rolling 24-hour cap	All launches in a moving window	Further launches revert until the window clears; queued requests resume automatically

Because both caps live in the contract, an offchain bug — a duplicated queue entry, a retry storm, a compromised scheduler — cannot spend past them.

What can go wrong, and what happens

• Unparseable post. No intent is produced; the agent replies asking for a clearer instruction.
• Out-of-range parameter. Rejected during binding, not clamped. A launch that does not match its instruction is a failure.
• Simulation mismatch. Nothing is signed. No partial state exists, because nothing was submitted.
• Onchain revert. The whole deployment unwinds. No orphan token, no unseeded pool, no unlocked liquidity.
• Cap breach. The launch is deferred until the rolling window allows it.

In every branch, the failure mode is no deployment rather than a wrong deployment. Once a launch does succeed it appears in Explore, and its implementation hashes can be checked against Contracts.