Lucrum Architecture: FOLLIS, FRS, Vestibulum, Tribunus Explained

Status note

Status note (updated August 25, 2026): Lucrum is an in-development protocol specification and contract monorepo. Its Phase 1 scope centers on Vestibulum, the FRS asset class, and Tribunus, but this article does not claim that those contracts are deployed, independently audited, or handling production funds. The broader catalog — Emporium, Creditum, Annuitas, Depositum, Nexum, Pensio, Fideicommissum, Sequester, Fiscus, Usura, and Guard — remains later-phase design work unless a versioned deployment says otherwise.

FOLLIS — the governance token

FOLLIS is a single ERC-20 governance and utility token — one contract per chain. It is not a separate family of tokens; it is one token, with one address per deployment chain.

Uses:

Governance voting. PlatformGovernor counts one voter unit per eligible address. Proposal and vote actions burn FOLLIS only when a nonzero burn configuration is enabled; zero disables that fee.
Staking collateral. Stake FOLLIS directly for yield, or pair it into an LP for higher yield.
LP pairing. FOLLIS LP tokens can be locked into FRS pools to earn FRS asset-class tokens (see the pipeline section below).
Burn events. A configured proposal or vote fee can burn FOLLIS, alongside any separately authorized supply reductions.

The checked-out EVM code has several FOLLIS issuance paths rather than two exclusive sources:

Forge liquidity mining. Forge.mineLiquidity calls the configured FOLLIS contract's mined-liquidity mint path. Its output is formula-driven, not a live market quote.
Vesting and staking rewards. Reward vaults can mint through an authorized token interface or transfer prefunded rewards, depending on configuration.
Planet NFT staking. Follis.sol mints accrued FOLLIS when staked Planet NFTs claim or exit.
Role-authorized minting. Follis.sol exposes mint(address,uint256) to accounts with MINTER_ROLE.

Those paths mean the repository does not support an “only through Vestibulum and LP staking” supply claim. A deployment needs documented role assignments, caps, and emission controls before its issuance policy can be evaluated.

Vestibulum — the onboarding gateway

Vestibulum (Latin: gateway / entrance hall) is the front door of Lucrum. It is how new users enter the ecosystem — by contributing to the kickstart LP or by vesting/staking existing assets for FOLLIS emissions.

The architecture treats onboarding state as deployment-specific. The checked-out EVM implementation splits the idea across Forge, a separate soulbound Vestibulum Participation Token (VPT), and FRSAirdrop; the Solana workspace has its own mining-rig and revenue programs. The repository does not establish a synchronized cross-chain OG database or portable OG status.

The kickstart contribution — it is NOT a deposit

This is the mechanic that must be communicated precisely: the Vestibulum kickstart is a contribution, not a deposit. Users send ETH to Vestibulum; the ETH does not come back. What actually happens:

User sends ETH to Vestibulum. In the current Forge contract, each transaction is capped at 5 ETH while totalMinedPositions <= 1000; the code does not apply that cap after the condition stops holding. During the capped period, a 21 ETH contribution requires at least 5 transactions (5 + 5 + 5 + 5 + 1 ETH).
The current call swaps half of msg.value toward the configured MEME asset and wraps the other half as WETH. After the initial boot, the desired amounts added to the shared Uniswap v3 position are divided by rig.virtualWeight, so the code does not show every contributed unit becoming new LP liquidity.
The position NFT is held by Forge. An owner-only decommissionRig path can decrease its liquidity, collect it, and forward recovered assets to ROMAN_FORGE; permanence and user redemption should not be inferred.
The call requests a FOLLIS mint to the caller and updates an internal scores mapping. The current Forge.sol does not call the separate VPT contract or create an OG-database record.

Nothing about the contribution is locked. FOLLIS is liquid immediately.

Score and FRS airdrops — design versus current wiring

Forge currently tracks its own score from liquidity, transaction frequency, and token balances. The separate FRSAirdrop contract does not read that score: it calculates a claim from historical delegated VPT voting power at an owner-selected snapshot block and an owner-configured ratio and allocation.

The VPT contract is designed so only its configured Forge address can mint participation tokens, but the checked-out Forge.sol does not invoke VPT. Each FRS airdrop must also be created and configured; it is not automatically attached to every FRS launch. “Lifetime Score airdrops” therefore remains an integration/design concept, not behavior established end to end by the current contracts.

Vest or stake (the non-contribution path)

Users who want to retain their underlying capital instead of donating it can vest or stake:

Vest an asset (e.g., LINK) in Lucrum → earn FOLLIS emissions at a moderate rate.
Stake an LP position (e.g., LINK/ETH on a supported exchange) → earn FOLLIS emissions at a higher rate.

The checked-out VestingVault accepts 1 through 12 periods of 30 days. It does not implement zero-lock or 7/30/90-day choices. A deployment would need to expose the exact vault version, configured reward token, lock period, and rate before a user deposits.

Tribunus — the DAO

Tribunus (Latin: tribune of the people — the Roman elected official who represented common citizens against the aristocracy) is Lucrum's governance design. The current PlatformGovernor implements one vote per eligible address, explicitly not token-proportional voting: at a snapshot, an address with delegated ERC20Votes voting power greater than or equal to the configured threshold in any approved FRS token contributes one voter unit.

That rule limits additional voting weight within one address, but it does not prove that one person controls only one address. An actor able to qualify many wallets can still gain many votes. The FRS threshold and optional FOLLIS burn fees raise participation costs, but they are not identity or Sybil resistance. The whitepaper lists optional identity staking as a future measure; it is not implemented by the current governor contract. One-address-one-vote therefore cannot support a claim that a whale is unable to acquire majority control.

Citizen qualification

To participate, an address needs delegated voting power greater than or equal to thresholdBalance in at least one token registered in the governor's FRS-token list. The contract checks current votes for present qualification and past votes at the proposal snapshot for voting; a raw token balance that has not been delegated is not the same signal.

Each proposal submission and vote can also burn a configured amount of FOLLIS. A nonzero fee can make repeated participation more expensive, but the governor permits a zero setting and the fee does not bind multiple addresses to one person.

What Tribunus controls

Which assets get integrated (new asset families entering the protocol — e.g., a proposal to wire Chainlink into Lucrum)
Which FRS asset classes launch next (FRS-wBTC, FRS-xAAPL, FRS-USDC, FRS-ETH, etc.)
Fee engine split percentages and destinations
Strategy whitelists for Fideicommissum trusts, Pensio pensions, Annuitas annuities
Nexum bond credit rating assignments (AAA through CCC)
Creditum Syndicatum lead-arranger appointments
Emergency pause / unpause across any product
Parameter changes across the entire suite (rates, caps, fees, slippage bounds)

How a proposal executes

Any FRS-qualified citizen submits a proposal — the configured FOLLIS proposal fee is burned if nonzero.
Community votes — one eligible address, one vote — with the configured vote fee burned if nonzero.
A successful proposal must be explicitly queued through the configured TimelockController; the applicable delay is its configured minDelay, not a hard-coded severity-based 24–72-hour table in PlatformGovernor.
After the delay, an external transaction must call execute. Passing and waiting do not execute a proposal automatically.

FRS (Fructus Revenue Shares) — an asset class, not a single token

FRS is not one token. FRS is an asset class, and each launch is a separate ERC-20 whose suffix declares what it pays in:

Token	Holders earn
FRS-wBTC	wBTC (wrapped BTC)
FRS-USDC	USDC
FRS-wETH	wETH (wrapped ETH for EVM smart-contract use)
FRS-wZEC	wZEC (wrapped ZEC for EVM smart-contract use)
FRS-xGOOGL	tokenized GOOGL (equity token, illustrative)
FRS-xAAPL	tokenized AAPL (equity token, illustrative)

More FRS tokens deploy over time — either by Tribunus DAO vote or by team-initiated launches. The FRS-w prefix denotes wrapped crypto variants (wBTC, wETH, wZEC) currently documented in the protocol specs. The FRS-x prefix for tokenized equities (GOOGL, AAPL, etc.) is illustrative of the intended pattern; specific equity listings will be DAO-proposed and subject to regulatory review. The list above is not exhaustive.

How to acquire FRS

Two paths:

Configured VPT airdrops. An owner can create an FRSAirdrop with an FRS token, VPT snapshot block, ratio, and prefunded allocation. Claims use historical delegated VPT voting power. This path is optional and is not currently wired to Forge's internal score.
Earn from a prefunded reward pool. The reward-system documentation describes FRS tokens being deposited into a distribution vault and transferred to eligible stakers. The pool is not described as minting new FRS on each reward claim.

What FRS tokens earn

The FRS design associates each series with a distribution asset: for example, FRS-wBTC is intended to receive wBTC and FRS-USDC to receive USDC. Current revenue-share documentation uses prefunded distribution vaults, so a symbol alone does not guarantee that reserves exist, that a distribution is due, or that an illustrative tokenized-equity asset is legally or technically available.

The proposed asset-to-FRS reward pipeline

Here is the design insight that ties the system together: any asset routed through Lucrum's pipeline ends up generating yield in a liquid denomination.

Worked example with LINK:

Vest LINK in Lucrum → earn FOLLIS emissions (moderate rate).
Or stake LINK LP (LINK paired into an AMM pool) → earn FOLLIS emissions (higher rate).
Take the earned FOLLIS, pair it into an LP on a supported exchange.
Lock the FOLLIS LP into a configured FRS reward pool.
If the pool is funded and the position qualifies, claim prefunded FRS-xxx rewards transferred from its distribution vault.
A separately funded revenue-share system can distribute the asset associated with that FRS series, subject to its actual contracts and reserves.

The intended pipeline turns a locked asset or LP position into eligibility for FOLLIS and then prefunded FRS rewards. It does not make LINK itself dividend-paying, guarantee a funded downstream distribution, or leave the asset continuously liquid. Exit depends on the exact vault, lock, and withdrawal implementation.

Emporium — the DEX

Emporium is Lucrum's multi-version decentralized exchange. V2 runs the AMM constant-product pool style; V3 adds concentrated-liquidity positions; V4 supports hook-based customization. Supporting all three in parallel lets LPs and traders pick the liquidity model that fits their strategy without fragmenting the ecosystem.

Creditum — the lending layer

Creditum is Lucrum's lending protocol: over-collateralized borrowing against supplied assets with interest rates set by utilization curves. Origination and interest-spread fees feed into the unified fee engine.

Creditum Syndicatum — syndicated loans

A variant of Creditum for syndicated structures: tranche-based credit facilities where lenders take different risk / yield positions on the same underlying loan. Bridges DeFi lending with institutional credit structure. Tribunus appoints the lead arrangers.

The unified fee engine

The broader specification proposes routing product fees through a unified engine with governance-set splits and destinations. That is an architectural target, not evidence that every current module is already wired to one deployed engine or that its ownership has been transferred to Tribunus.

Destinations include:

Guard insurance reserve (customer-facing loss protection)
FRS-backing flows (funding FRS pools that pay FRS-holder yields in their denominated asset)
User cashback / engagement rewards
Protocol treasury (Tribunus-governed spending)

Specific percentages are not hard-coded here because they are governance parameters that can change via DAO vote.

The yield engine — Fiscus + Usura + FRS pools

Fiscus — curated strategy pools. Depositors pick a risk profile; Fiscus allocates across Lucrum and external opportunities per the pool's mandate.
Usura — a route-based compounding layer. Its current contract exposes an explicit permissionless compound call; “auto-compounding” still needs a caller or keeper.
FRS pools — asset-class-specific reward and revenue-share distributors whose current design relies on prefunded rewards and distribution assets.

TradFi-on-chain modules (later-phase)

These ship across subsequent eras after Phase 1:

Annuitas — on-chain annuities (Variable, Fixed-Term, Guaranteed-Tier)
Depositum — fixed-rate certificates of deposit
Nexum — on-chain bond issuance with Tribunus-assigned credit ratings
Pensio — decentralized pensions with target-date glide paths
Fideicommissum — irrevocable on-chain trusts with generational payout schedules
Sequester — yield-generating escrow

Each is a first-class module in the monorepo, not a bolted-on third-party product.

Guard — insurance

Guard is Lucrum's proposed insurance layer, intended to use protocol-fee allocations and optional premiums for specified risk pools. Coverage terms, funding, claims, governance, and payout mechanics require a versioned implementation and review; the module name is not evidence of insurance coverage.

Multi-chain

Lucrum's proposed initial deployment is EVM-first — Ethereum and EVM-compatible L2s. The design gives each deployment its own FOLLIS contract, Vestibulum launch, OG database, fee engine, and module instances. Vestibulum OG status is specified as per-chain. Cross-chain FRS portability is designed around a burn-and-mint mechanism; this article does not claim that bridge logic is deployed or audited.

Solana support is already represented in source, not merely on a roadmap: protocol/platform-core-sol contains a Solana-native workspace with mining-rig, FRS-revenue, reward-boost, SDK, and governance scaffolding. Its README also labels the Raydium and Orca adapters as lightweight mocks to be replaced, so source presence is not deployment or production-readiness evidence.

What's next

Annuities On-Chain: How Lucrum's Annuitas Module Works — later-phase deep dive
Tribunus Citizenship: One Address, One Vote, FRS-Qualified — upcoming
The FRS Asset Class: FRS-wBTC, FRS-xGOOGL, and the Pipeline Beyond — upcoming
Vestibulum Score: Gamified OG Status and Lifetime FRS Airdrops — upcoming

Or browse the Lucrum product page for the module catalog and current development status. The public architecture source is the Lucrum monorepo; verify contract versions, tests, audits, and deployment addresses before relying on any module.

Continue reading

Current Lucrum project information