Transparency

Every section below reduces to a read against Base mainnet.

Start here: the cap is a number

maxSupply() on the LOAM contract returns 1,000,000,000. That is the cap, written once at genesis and never raised. totalSupply() returns what has actually been issued — the LOAM that exists. The difference, reserveBox(), is unissued capacity: a counter, not a balance. The token contract holds no LOAM.

Until 2026-09 the unissued capacity was pre-minted and held at the token's own address, and every automated risk scorer read that balance as a single holder of 99.4% of supply. It was never a holding — it could leave the contract only when someone paid NAV in Pinto — but a scanner keys on the balance, not the explanation. The pre-minted reserve was burned in one timelocked upgrade (tx); nothing about NAV, circulating supply, fees or redemption changed, and this page shows the three reads that let you check that.

The rest of this page is the evidence: the allocation identity and the calls behind each term, the founder escrow's schedule, both pools read from chain, the upgrade path and who controls it.

Allocation

Three independently checkable reads. totalSupply() is outstanding LOAM; the protocol's own liquidity position is part of it; the cap is what may ever exist.

maxSupply()= totalSupply() + reserveBox()

circulatingSupply()= totalSupply() − protocolLpSurco()

Circulating — circulatingSupply()—

Protocol LP — protocolLpSurco()—

Unissued capacity — reserveBox()—

Issued as a share of the cap—

The token contract's own balance of LOAM is zero — balanceOf(0x473B…A31b) — and the deployer's balance is zero.

Vesting

There is one founder allocation, it is locked, and it is the largest non-protocol balance in the system. It sits in a stock OpenZeppelin VestingWallet, deployed at genesis and used unmodified — no custom escrow contract was written, and the deployed bytecode is checkable against the library's own.

Escrow contract0xEa29F43467be0f004c331DD8015FC5F80d8B0A92

Held — balanceOf(escrow)—

Released so far — released(token)—

Releasable today — releasable(token)—

Vesting starts — start()—

Fully vested by — start() + duration()—

The schedule above is not a policy anyone promises to follow — it is start and duration on a deployed contract, and the same read anyone can make. Nothing releases before start(); that IS the widely-described "cliff" — the contract has no separate cliff mechanism, it is simply a start timestamp in the future. From that point release is linear over duration.

⚠️ Two accepted properties, disclosed rather than papered over. OpenZeppelin's VestingWallet is Ownable with the beneficiary as owner, so the position itself is transferable — the beneficiary could sell it. That changes who eventually receives the tokens, never when: a buyer inherits the identical start and duration and cannot release a single token early. The escrow is also non-revocable — stock VestingWallet has no claw-back function, and none was added. The beneficiary is readable at any time via owner() on the escrow.

Liquidity

LOAM trades against USDC in two Aerodrome pools on Base. Each pool's balances are read live from the token contracts themselves — the same balanceOf call anyone can make — and LOAM's price is derived from the v2 pool's own reserves, never fetched from a price API.

Pool — Aerodrome Slipstream CL, tickSpacing 1, fee 0.01%0x063Af815f7e31f22f55d8ce0f74C4F1431f14B9C

LOAM — balanceOf(pool)—

USDC — balanceOf(pool)—

Pool value (TVL)—

Pool — Aerodrome v2 volatile0x61532c816bE0e766d77aAbA78C37F8C4C8f9Ab9D

LOAM — balanceOf(pool)—

USDC — balanceOf(pool)—

Pool value (TVL)—

⚠️ There is no liquidity lock. The protocol's liquidity is protocol-owned — protocolLpSurco() reports the LOAM side of it — but it is not deposited in any third-party locker, and "protocol-owned" is not the same claim as "locked". What constrains this protocol is stated elsewhere on this page: a 48-hour timelock on every upgrade, a non-revocable founder escrow that has released nothing, and a staking contract with no admin at all.

Governance

Every protocol upgrade runs through one path: the Safe proposes, the TimelockController holds the proposal for 48 hours, and only then can diamondCut execute. There is no direct-call path from the Safe (or anywhere else) to diamondCut that skips the timelock — the diamond's cut function accepts calls only from the timelock's own address.

Proposer — Safe0x4280F2b1fc6edbBbaE69b7F651f09357057b8D0F

Holds every proposal — TimelockController0x6Cf2879291A343514F62c55448306a3f5E45EF9f

Delay — getMinDelay()172800 (48 hours)

Canceller — can pull a queued proposal, cannot execute one early0x7d81AeE0AB78D7a149420BfFFA6074E85DE735a3

Guardian — holds GUARDIAN_ROLE, can halt redemptions and minting instantly, with no timelock0xc11D0a80F2f3ff6eba46cdB4f6CD3b0ff2D53beF

The canceller and the guardian are not independent parties. getOwners() on the Safe returns three signers with a threshold of 2, and two of those signers are the canceller and guardian addresses above. These are role separations inside one signer set, not separate organisations — one call exposes it, so it is stated here rather than left to be found.

The only executable target on the diamond that changes code is diamondCut itself, and it runs through the queue above. So does every other change that could redirect value or control: role grants, the mint and redeem fees, the venue adapter, and devAddr. None of those can take effect on a timeline shorter than 48 hours, and each is visible on Basescan the moment it is queued — not the moment it lands. Nothing about the facet set, the allocation, the vesting escrow, or the protocol's liquidity position can move faster than that.

⚠️ Two things are not delayed, and this page does not claim they are. The guardian can call AdminFacet.latchRedemption(string) or AdminFacet.latchMint(string) — both onlyRole(GUARDIAN_ROLE) — and halt every redemption, or every mint, immediately. Each takes a non-empty reason string that is emitted on-chain with the latch, and the Safe can lift a latch, also immediately. Separately, AdminFacet carries parameter setters gated on DEFAULT_ADMIN_ROLE, which the Safe holds, and they take effect the moment they are called: the cushion floor and ceiling, the performance fee, the referrer, the Field exposure cap, the earmark ceiling, the max swap slippage, the stem-scan budget, and disableVenueDivergenceGate (that last one is callable by the guardian as well). They change parameters rather than code. The full list is in src/facets/AdminFacet.sol, and every one of them is an onlyRole(DEFAULT_ADMIN_ROLE) or onlyRole(GUARDIAN_ROLE) line a reader can grep for.

Contract safety

The sections above are about what can change and who can change it. This one is the opposite: properties that hold in the deployed source. Each is checkable without trusting this page: the contracts are verified on Basescan, so the source is readable at the address itself, and the repository they are built from is public at github.com/Project-Loam/loam-contracts.

The source is verified and public. Basescan carries verified source for the diamond and for each facet behind it, and GoPlus reports is_open_source = 1. Nothing about this token's behaviour has to be inferred from bytecode — the facet addresses to read are listed live from the diamond's own loupe on /technical.

The deployer holds nothing. balanceOf(0x6d0bfe8fd0d8e725044f41750353f58368eb2a95) on the token returns zero, and GoPlus reports creator_balance = 0. The address that deployed these contracts has no position to sell. It is an EOA, which is why it is not in the Addresses table below.

The transfer path is a plain ERC-20 transfer. TokenFacet.transfer and transferFrom each do one thing: call LibToken.transfer, which rejects the zero address on both sides, checks the balance, and moves the full amount. There is no fee skim, no blacklist or allowlist mapping, no pause flag and no per-address gate anywhere on that path, and no function in the source moves a balance its caller does not own except through the ordinary allowance. transferFrom spends that allowance first, and an infinite approval is the only one it does not decrement. Read src/facets/TokenFacet.sol and src/libraries/LibToken.sol — both are short. This claim is made from the source, not from a scanner. The tax and honeypot fields a scanner would normally supply come back empty for LOAM, because they are populated only from the DEX listings the scanner indexes, and the two Aerodrome pools read live in Liquidity above are not among them.

The cap is fixed at genesis, and no path can exceed it. maxSupply is written once, by InitFacet at genesis behind a once-only guard (require(s.maxSupply == 0)) — grep src/ for s.maxSupply = and there is exactly one hit, and no function anywhere writes it again. LibToken.mint runs on every mint, at genesis LP seeding and on a protocol deepen; LibToken.burn runs on every redeem, and ran once more in the timelocked upgrade that retired the pre-minted reserve. Each call moves totalSupply() and reserveBox() by equal and opposite amounts, so totalSupply() + reserveBox() — the cap — never moves.

The staking contract has no admin at all. vLOAM at 0x3e17f7b0c50509099c99A7E3512b793ca03213ac is verified, and it has no owner, no pause, no setter and no proxy. grantBps and ramp are immutable, fixed at construction and emitted once in a Deployed event. Its own header comment states the intent — "NO ADMIN, DELIBERATELY" — and the code matches it: nothing can change the staking curve and nothing can drain custody through an admin function, because no such function was written. Changing the curve would mean deploying a second contract and letting stakers move to it.

Mint and redeem are permissionless and priced at NAV. mint(uint256) and redeem(uint256) on the diamond carry no role check, no allowlist and no per-caller cap — anyone can call them directly against the contract, from a wallet or a script, without this site or any front end. previewMint and previewRedeem are view functions: they quote the exact output and fee before anything is signed, and change no state. The one thing that can stop either is the guardian latch disclosed in Governance above, which is on-chain and emits its stated reason with the halt.

Addresses

Every contract referenced anywhere on this page, in one place. Facet addresses are deliberately not listed here — they are read live from the diamond's own loupe on /technical, because a transcribed facet address is wrong the moment an upgrade lands; everything below is stable across upgrades.

LOAM token / diamond0x473B392018B05ecbB7Edf4C3CF2B1F8593A9A31b

TimelockController0x6Cf2879291A343514F62c55448306a3f5E45EF9f

Safe (proposer)0x4280F2b1fc6edbBbaE69b7F651f09357057b8D0F

Canceller0x7d81AeE0AB78D7a149420BfFFA6074E85DE735a3

Guardian0xc11D0a80F2f3ff6eba46cdB4f6CD3b0ff2D53beF

vLOAM staking0x3e17f7b0c50509099c99A7E3512b793ca03213ac

Founder escrow0xEa29F43467be0f004c331DD8015FC5F80d8B0A92

Well (PINTO/LOAM)0x7474Ed426b39590122dFF304D03CA56e36E3E782

PINTO0xb170000aeeFa790fa61D6e837d1035906839a3c8

Facets: read live from IDiamondLoupe.facets() on the diamond above, rendered on /technical.

Not yet claimed

The rest of this page is evidence for what LOAM does. This section is deliberately the opposite: what a reviewer would otherwise have to find on their own.

There is no liquidity lock. Both pools' liquidity is protocol-owned, not deposited in any third-party locker — see the Liquidity section above for the full statement and what constrains the protocol instead. What that means in practice: the position belongs to the protocol rather than to a founder wallet, and the deployer's balance is zero. There is no insider LP that could be pulled — only an unlocked protocol-owned one.

There is no third-party audit. Internal security review exists — a full multi-agent audit of the v1 codebase, a board review of the v2 design, and a hardening-cut pre-review — but no firm has been commissioned, and the pre-genesis full-suite audit is scoped rather than performed. No firm's name appears anywhere on this page, because none has looked at this code. What stands in for one until that changes: the entire source is verified and public — see Contract safety above — so a reviewer, a firm, or anyone else can read every line of it without asking us for anything.

Liquidity is thin. Combined depth across both pools, read live from chain. Thin in absolute terms, and thinner still against the cap — but measured against issued supply rather than the cap, these pools hold a large share of the float rather than a sliver of it. Divide the Liquidity figures above by the Allocation figures above to check it; both sides are live reads.—

The protocol takes a 10% performance fee on realised Silo yield, and it is paid to the founder escrow. The rate is read from perfFeeBps() on the diamond, which returns 1000 bps. It is charged only on yield the reserve actually realises — not on a mint, a redemption, or the reserve principal — and is paid in PINTO to devAddr(), which returns 0xEa29F43467be0f004c331DD8015FC5F80d8B0A92: the same founder escrow address whose vesting schedule is published above. Both are one call each. What the fee is not: it is never taken from a holder's balance or from a transfer, and never charged on principal, on a mint or on a redemption — the transfer path skims nothing, which Contract safety above shows in the source. It exists only where the reserve realises yield, and its rate is a public read anyone can check at any time.

Holders are few, and none of them is an EOA. The addresses holding LOAM today are contracts — the founder escrow, the staking contract, the liquidity pools — not individual wallets accumulating a position. Each of them is named in the Addresses table above. That is what an early protocol-owned float looks like: held by the protocol's own contracts rather than distributed to holders, which a holder-count check reads as concentration even though the token contract itself — the address a scanner used to flag before the 2026-09 cut — now holds none of it.

Verify it yourself

Every figure on this page reduces to one of these reads. Run them yourself against Base mainnet with cast; nothing here depends on trusting this site.

L=0x473B392018B05ecbB7Edf4C3CF2B1F8593A9A31b
E=0xEa29F43467be0f004c331DD8015FC5F80d8B0A92
cast call $L "maxSupply()(uint256)"             # the cap: totalSupply() + reserveBox()
cast call $L "totalSupply()(uint256)"           # issued
cast call $L "circulatingSupply()(uint256)"
cast call $L "protocolLpSurco()(uint256)"
cast call $L "reserveBox()(uint256)"            # unissued capacity — a counter, not a balance
cast call $L "balanceOf(address)(uint256)" $L   # the token contract's own LOAM balance: 0
cast call $L "mintFeeBps()(uint256)" ; cast call $L "redeemFeeBps()(uint256)"
cast call $L "perfFeeBps()(uint256)" ; cast call $L "devAddr()(address)"   # 1000 bps, paid to the founder escrow
cast call $E "released(address)(uint256)" $L ; cast call $E "releasable(address)(uint256)" $L
cast call $E "start()(uint256)" ; cast call $E "duration()(uint256)"
cast call 0x6Cf2879291A343514F62c55448306a3f5E45EF9f "getMinDelay()(uint256)"
cast call 0x4280F2b1fc6edbBbaE69b7F651f09357057b8D0F "getOwners()(address[])"   # the Safe's three signers
cast call $L "balanceOf(address)(uint256)" 0x6d0bfe8fd0d8e725044f41750353f58368eb2a95  # deployer EOA: 0
cast call $L "previewMint(uint256)(uint256,uint256)" 1000000   # quote a mint without signing anything
V=0x3e17f7b0c50509099c99A7E3512b793ca03213ac
cast call $V "grantBps()(uint256)" ; cast call $V "ramp()(uint256)"   # vLOAM immutables; no setter exists