Contracts
What is deployed, and what each contract is allowed to do.
The six deployed once
| Contract | What it does | Can it be changed |
|---|---|---|
| VerdantHook | Answers the pool's fee question on every swap and refuses any pool it did not authorise. | No. Its address encodes its permissions. |
| VerdantFactory | Creates a market atomically: token, pool, liquidity, lock, registration. | No. Its counterparties are immutables. |
| ModelRegistry | Holds the bounds a launch is validated against and the protocol's fee share. | Bounds for future markets only. A created market snapshots what applied to it. |
| MarketRegistry | The public record of every market created. | Append-only. |
| VerdantDeployer | Deploys each market's token, splitter, locker and vesting. | No. |
| FactoryOrigin | The anchor the factory's address derives from. Can create once. | No. |
Per market
Every launch also creates its own token, splitter and locker, and a vesting contract if an allocation was withheld. They are listed on the market's page, with links to the explorer, because a claim about where fees go should be checkable against the contract that holds them rather than against this interface.
What has no owner
The token has no mint function and no owner. The locker has no operator and no early-release path. The splitter's recipients are immutable clone arguments. The hook has no admin function at all. The registry owner can change bounds for future markets and cannot touch an existing one.