Documentation
Introduction
ALMERU turns a sentence into a working onchain economy. You post an instruction in plain language, the agent compiles it into a fixed parameter set, deploys the contracts in a single atomic transaction on Robinhood Chain, and replies with the addresses.
What the agent actually does
A launch begins in public. Someone writes what they want — a token with a staking programme, a reserve that grows out of trading fees, a round-based mining game — and mentions @almeruagent in the post. The agent reads the request, resolves it into a complete parameter set, and deploys the economy that request describes: the token, the pool it trades in, the treasury that accumulates behind it, and whatever reward machinery the instruction implies.
None of that is stitched together after the fact. The contracts are deployed together, wired to one another during deployment, and handed over in a state that already works. There is no follow-up transaction in which the creator has to switch the protocol on, and no window during which a half-configured economy sits exposed on chain. Either the whole thing exists when the block closes or none of it does. The atomicity guarantee, and the module set it applies to, are described in Protocol architecture.
When a deployment lands, the agent posts the resulting addresses back into the same thread it was asked from. Every launch is also indexed in Explore, and the implementation set behind it can be inspected from Contracts.
What ALMERU is not
ALMERU is not a custodian, not an exchange and not a decentralised exchange. It holds no user funds, accepts no deposits, and is never the counterparty to a trade. It is a deployment mechanism with a market integration — and that distinction is the frame for everything else in these docs.
The agent has exactly one privileged capability: it can sign a deployment transaction from a managed wallet whose authority is constrained by contract, not by convention. It cannot move a user's balance, cannot upgrade a protocol that has already shipped, and cannot reach into a treasury it deployed last week. Wallets and authority sets out what that wallet may and may not do; Security model covers the caps and the failure modes.
Supply is bounded in the same spirit. Every token ALMERU deploys is capped at 1,000,000,000 units, and no minting path survives deployment. There is no inflation schedule, no team faucet, no emergency issuance. Any reward a protocol pays out has to come from inventory the protocol already holds — a constraint that shapes the whole of Treasury mechanics.
Two templates
Treasury protocol
A token paired with staking, bonds, buybacks and a reserve. Trading fees route into the treasury, the treasury backs the token, and stakers are paid from inventory that was set aside at launch. See What launches.
Miner
A 25-tile, round-based game economy. Tiles are claimed and worked over discrete rounds, with the same fixed-supply token and locked-liquidity rules underneath. See Miner protocol.
Both templates share one canonical pool, one fee split and one liquidity lock. What differs is the reward surface bolted on top: a treasury protocol pays through staking and bonds, a Miner pays through round settlement. The market layer is identical either way and is documented in Market integration.
Fixed parameters
A handful of values are not negotiable at deploy time. They are compiled into the implementation set, not passed in as arguments, so no instruction — however it is phrased — can move them.
| Parameter | Value | Set by |
|---|---|---|
| Network | Robinhood Chain, chain ID 4663 | Fixed |
| Token supply | 1,000,000,000, non-mintable | Fixed |
| Canonical pools | One per launch | Fixed |
| Liquidity | Locked permanently at launch | Fixed |
| Launch fee | 0.0005 ETH | Fixed |
| Pool trading fee | 1%, split 70% creator / 30% protocol | Fixed |
| Bootstrap size | 0.0001 – 0.07 ETH | Requester, within range |
| Reward route | e.g. 40% holders / 60% reserves | Requester, at deploy |
Where the model stops
A language model is involved in exactly one step: turning an English sentence into an intent. It never produces an address, an amount, a cap or a function selector. Those are supplied by deterministic code from a registry of pinned implementations, and the assembled transaction is simulated against live chain state one block before it is executed. If the simulation disagrees with the intent, nothing is signed. The full sequence is in From post to protocol.
Where to go next
Command reference
The phrasings the parser recognises and the parameters each one binds. Read →
Treasury mechanics
Staking receipts, bond escrow, buybacks and balance separation. Read →
Security model
Rolling value caps, simulation, and what the agent cannot reach. Read →
If you are here to look at a live deployment rather than to read about the mechanism, start at Explore or open Portfolio after you connect. Terms of use are in the legal notice.