The Loam protocol specification
This document describes the protocol that is actually deployed on Base, in the terms a reviewer checks it in. Every figure below is a genesis constant or a governed parameter, named beside the on-chain call that returns it. Where a number moves — circulating supply, pool depth — this page does not print it; it points at /transparency, which reads it live instead of transcribing a value that will already be stale by the time this page is read.
1. What LOAM is
LOAM is an ERC-20 token on Base. Each LOAM in circulation is a redeemable claim on a share of a reserve the protocol holds in Pinto. It is minted by depositing Pinto into that reserve and redeemed back out of it; both directions are priced at the protocol's net asset value, computed on-chain and quotable before signing anything. LOAM is not a stablecoin and makes no promise to hold a fixed price — the reserve it draws value from is itself denominated in an asset that moves, which the next section explains before anything else here can be evaluated.
2. What Pinto is
Pinto is a separate protocol on Base — not ours, not operated by us, and not a token we control in any way. It issues a credit-based stablecoin, PINTO, that targets one US dollar by expanding and contracting supply on an hourly cycle rather than by holding collateral against it. PINTO has been trading below that target. A target is not a guarantee, and everything in this document that is denominated in Pinto — the reserve, net asset value, the risk section — inherits that fact rather than escaping it.
3. Net asset value
Net asset value is the amount of Pinto standing behind one LOAM, and it is what mint and redeem are priced against. It is computed entirely from protocol-owned, on-chain balances — the Pinto the reserve actually holds against the LOAM actually issued — never from a market or pool spot price. Because it never reads a price surface that a single transaction can move, there is no in-block manipulation for NAV to be flash-loaned through.
The function and access-control surface behind this call — the full facet map, read live rather than from a deployment record — is catalogued on /technical, not repeated here.
4. Mint and redeem
Both directions are permissionless: anyone can call them directly against the contract, and either side can be quoted before committing to it with previewMint(uint256) or previewRedeem(uint256), neither of which changes state.
Both rates are read from the contract; the figures above are simply what those getters return. The mint fee and the redeem fee are retained by the reserve rather than paid to anyone — that statement is about those two fees and no others. The protocol charges a third fee, on realised Silo yield, and that one is paid out; it is described immediately below.
⚠️ Redeeming burns, as of the 2026-09 mint-on-demand upgrade. Per ADR 0046, a partial supersession of ADR 0029: the full LOAM amount being redeemed is destroyed, and reserveBox() — unissued capacity — is credited by the same amount. ADR 0029's guarantee still holds: mint-at-NAV stays perpetually available, because the counter goes back up by the full amount. What changed is only that the tokens are destroyed rather than parked at the diamond. The redeem fee is not a separate chunk carved off and burned; it is a haircut on the Pinto payout, so the redeemer simply receives less Pinto than a fee-free redemption would return, while the entire LOAM amount handed in is burned regardless. The Redeemed event's burned field again carries the full redeemed amount, exactly as its name says.
The performance fee
Reserve Pinto is deposited into Pinto's Silo, which pays yield when Pinto is at or above its target. The protocol takes a 10% performance fee on that realised yield. It is charged only on yield actually realised — never on a mint, a redemption, or the reserve principal — and unlike the two fees above it is paid out rather than retained.
devAddr() returns the same address as the founder escrow whose vesting schedule is published on /transparency. The accrual is in LibSilo.plantAndCompound: 10% of each realised harvest is booked to owedDevPinto and transferred in PINTO to devAddr() as deposits mature. Both terms are one call each against the diamond — perfFeeBps() and devAddr().
5. Supply
maxSupply() returns 1,000,000,000. That is the cap, written once at genesis and never raised. totalSupply() is what has actually been issued; the difference, reserveBox(), is unissued capacity — a counter the contract keeps, not tokens it holds. The token contract's own LOAM balance is zero. The identity is exact and every term in it is a public call —
Until 2026-09, unissued capacity was pre-minted and held at the token's own contract address — the same balance every automated risk scorer read as a single holder of the overwhelming majority of supply. It was never a holding: it could leave the contract only when someone minted against deposited Pinto. That pre-minted reserve was burned in a timelocked upgrade; nothing about NAV, circulating supply, fees or redemption changed, and /transparency shows the three reads that let a reviewer check that directly.
The live values behind that identity — what has actually been issued, what sits unissued, and what share of the cap that represents — are read on-chain and shown on /transparency rather than printed here as a literal, because they move: a figure quoted in this document would already be wrong by the time it is read.
6. Staking and vLOAM
LOAM can be staked into a separate, non-upgradeable contract that reports a second, non-transferable balance called vLOAM. vLOAM measures time staked, not amount deposited: it starts at a fraction of the staked amount and ramps toward the full amount over four years.
vLOAM does not vote today. Governance, described next, runs through the Safe and timelock below; vLOAM is not wired into it or into any other governance surface. It is a duration measure other surfaces can read, and no more than that is built. grantBps and ramp are immutable, fixed at deployment with no setter — the curve cannot change underneath a staker. The full function surface, including why vLOAM emits no Transfer events, is on /technical.
7. Governance
LOAM is an EIP-2535 diamond: calls route to facets by selector, and every change to that facet set is a diamondCut. There is no path to diamondCut that skips the chain below it.
The Safe queues a change, and it cannot execute one before the 48-hour delay elapses. It holds EXECUTOR_ROLE as well as PROPOSER_ROLE — it is the only executor, and the zero address does not hold that role, so execution is not open to the public — but that role only lets it submit the execution transaction once the delay has run. The account that calls diamondCut is the timelock itself: the diamond's owner() is the timelock address, so the timelock, not the Safe, is msg.sender to the cut. Between queueing and execution the scheduled change is visible on-chain to anyone watching. The access-control chain, traced against the deployed bytecode rather than assumed from convention, is on /technical.
Not every privileged action runs through that queue. A set of parameter setters on AdminFacet is gated on DEFAULT_ADMIN_ROLE, which the Safe holds, and those take effect the moment they are called, with no delay; the guardian's latches, described in the next section, are instant too. /transparency lists both sets. What is timelocked is the code itself — diamondCut — along with role grants, the mint and redeem fees, the venue, and devAddr.
8. Risks
Stated flatly, because a risk list that softens its own claims is not a disclosure:
None of these is hypothetical or deferred to a future version: they are properties of the mechanism as deployed today, and they hold regardless of how the token performs.
9. What is not built
An earlier document describing this protocol's predecessor, Surco, promised a roadmap of features beyond what shipped — and separately, in its own "live today" list, described a fee router that paid stakers a share of protocol revenue. Neither the roadmap items nor that reward exist in the deployed contracts, and this document does not describe any of them as forthcoming or partially built — only as absent:
Staking pays no reward today. The staker share of protocol fees is a fixed constant in the code, not a governed setting that could be raised — it is 0 bps, and no facet exists in the deployed diamond to distribute a staker reward even if it were not. vLOAM, described above, measures staked duration only; it is not a claim on any fee stream.
Unlike Hyper-Burn, the credit portal, and the emergency liquidity manager — for which no source exists at all — a FieldFacet.sol does exist in the public source repository. Its existence in source is not evidence it is live: it is one of the facets the deployed diamond never cut in, and that is checkable directly, not asserted here. /technical reads the diamond's own IDiamondLoupe.facets() live, so a reviewer can confirm against the deployed bytecode that no such facet is part of it, rather than taking this page's word for it.
Every mechanism this document describes elsewhere — minting, redeeming, staking, governance — is complete and deployed as written. Nothing above is partially built or scheduled for a near-term upgrade; a future diamondCut could add any of it, but doing so would itself be a governed, timelocked change, disclosed through the same 48-hour window described in governance.
10. Status
This document supersedes the earlier "Surco Whitepaper v2". That paper described a different token: a fixed supply ten times smaller than this token's 1,000,000,000 cap, 1% mint and 1% redeem fees against the 30 bps / 50 bps actually charged, and a roadmap of unbuilt features listed above as though under way. Where the two disagree, this document and the deployed contracts govern — not the earlier paper.