Documentation

Protocol architecture

Every ALMERU launch is assembled from eleven modules drawn from a pinned, registered implementation set. The factory will not deploy anything else, and a launch either completes in full or reverts entirely.

The module set

A deployed economy is not a monolith. It is eleven contracts with narrow responsibilities, wired together during the deployment transaction. Splitting them this way keeps each contract small enough to reason about, and it makes the authority boundaries explicit: a module that cannot move funds does not have a function that moves funds.

Module	Responsibility
`AlmeruFactory`	Entry point for a launch. Deploys the module set atomically and refuses any implementation that is not registered and pinned.
`AlmeruTreasury`	Holds protocol assets and keeps free, backing, bond and operating balances separated.
`AlmeruStaking`	Accepts deposits and issues receipts. Pays rewards only from inventory the protocol already holds.
`AlmeruBonds`	Runs bond windows with per-epoch capacity caps and full pre-escrow of every payout.
`AlmeruBuyback`	Executes treasury-funded buying in the canonical pool under price-protection constraints.
`AlmeruOracle`	Maintains the time-weighted average price and the harmonic-liquidity floor used by buybacks and bonds.
`AlmeruLocker`	Holds the launch liquidity position permanently and compounds its fees in place.
`AlmeruExecutor`	The only contract the managed wallet may call. Translates a validated intent into module calls.
`AlmeruRegistry`	The allow-list of implementation hashes the factory is permitted to deploy.
`AlmeruTimelock`	Delays every parameter change that is changeable at all, so nothing takes effect in the block it is proposed.
`AlmeruGuard`	Enforces the rolling 24-hour value cap and the per-launch cap, and can halt execution without touching deployed protocols.

Pinned implementations

The factory does not accept arbitrary bytecode. It accepts an implementation set — a specific combination of module versions, each identified by a hash recorded in AlmeruRegistry. If a hash is not in the registry, the factory reverts before it deploys anything. This is what makes the deployed protocol predictable: a launch from last week and a launch from this morning either share an implementation set or they do not, and which one applies is visible on chain rather than inferred.

Registering a new implementation set is a timelocked operation. It goes through AlmeruTimelock, and it never applies retroactively — protocols already deployed keep the implementations they were deployed with, permanently. There is no proxy upgrade path, so a registry change alters what future launches look like and nothing else. Current hashes are published under Contracts.

Atomicity

A launch is a single transaction. Inside it, the factory deploys all eleven modules, mints the fixed supply, seeds and locks the pool, sets the reward route, and hands ownership of the mutable parameters to the timelock. Any failure at any point in that sequence reverts the whole transaction.

launch()
  ├─ verify implementation hashes    → revert if unregistered
  ├─ verify caps with Guard          → revert if over rolling or per-launch cap
  ├─ deploy modules (11)
  ├─ mint 1,000,000,000 · disable mint path
  ├─ seed canonical pool
  ├─ transfer LP position → Locker (permanent)
  ├─ write reward route + bond/staking config
  └─ hand parameters → Timelock
  ⇒ all of the above, or none of it

The practical consequence is that there is no partially-launched state to defend against. You never encounter a token whose pool was not seeded, a staking contract with no reward inventory, or a locker that was skipped. Any of those would have reverted the deployment.

Authority boundaries

The managed wallet the agent signs with has one callable target: AlmeruExecutor. It cannot call the treasury, the staking contract or the locker of any deployed protocol, and it holds no role on them. The executor itself is constrained to a fixed instruction set — it can request a launch, and it can perform the narrow set of post-launch operations a protocol explicitly exposes. It cannot invent a call.

AlmeruGuard sits in front of the executor and enforces two limits: a per-launch value cap, and a rolling 24-hour cap on total value committed across all launches. If either would be breached the call reverts. The guard can also halt new executions entirely; halting stops the factory from deploying, and has no effect on protocols that already exist. Nothing in the system can pause, drain or reconfigure a deployed economy. See Wallets and authority and Security model.

How the modules interact

The oracle is the shared dependency. AlmeruBuyback reads a time-weighted average price and a harmonic-liquidity floor from it before spending, and AlmeruBonds reads the same values when pricing a discount, which is why a bond cannot be priced off an instantaneous quote. AlmeruTreasury is the shared ledger: bond escrow is a treasury balance flagged as committed, buyback budget comes from the free balance, and reserves are accounted separately from both. The full accounting model is in Treasury mechanics, and the market side of the oracle and locker is in Market integration.