Revenue Sources
Treasury yields, AMN profits, and protocol fees flow into the engine
Distribution Engine
Automatically allocates revenue based on coded rules, not votes
PODs
Purpose-Oriented Distributors that fund specific protocol needs
Self-Sustaining
Revenue reinvested creates a flywheel effect for growth
Interactive Distribution Engine
Watch how revenue flows from the protocol to each Purpose-Oriented Distributor (POD). Click on any POD to learn more.
How the Flow Works
Revenue Generation
The protocol generates revenue from multiple sources: yields from the Treasury's stablecoin holdings, profits from the Automated Market Navigator (AMN), and various protocol fees. This creates a diversified income stream.
Automatic Distribution
Revenue flows into the Distribution Engine, which automatically allocates funds to each POD based on pre-coded percentages. No governance votes needed—the system runs itself according to its design.
Purpose-Driven Allocation
Five named PODs serve specific purposes: Developers (funding protocol development),Creatives (community and ecosystem growth),Creditors (rewarding PACT holders who became lenders),Reserve Booster (strengthening the Vault), and Liquidity Booster (ensuring market depth).
Flywheel Effect
As the protocol grows, it generates more revenue, which strengthens all PODs, which makes the protocol more robust, which attracts more users, which generates more revenue. This is the self-sustaining flywheel at the heart of 3.Finance.
The Fortify/Thrive Decision
At the core of the Distribution Engine is an unchangeable code law: before any revenue is distributed, the engine checks the Reserve Requirement.
Fortify Mode
Reserve Below TargetWhen The Vault's ETH reserves are below the Reserve Requirement Curve (RRC), the engine enters Fortify Mode. ETH revenue is directed to The Vault to strengthen sovereign backing.
Thrive Mode
Reserve At/Above TargetWhen The Vault meets or exceeds the RRC, the engine enters Thrive Mode. ETH revenue flows to the five PODs—Developers, Creatives, Creditors, Reserve Booster, and Liquidity Booster—enabling growth and rewards.
Unchangeable Code Law
The Fortify check is hardcoded and immutable—no governance vote can override it. This ensures the protocol always prioritizes sovereign backing before discretionary spending. Human/AI governance can only adjust the target (the RRC), not bypass the check itself.
The Redirect Variable: Self-Healing in Action
In addition to Fortify/Thrive, the Redirect Variable handles Settlement Pledge pressure. When too many redemptions occur, revenue automatically redirects to refill the pledge— like a pressure relief valve responding to excess demand.
Automatic Protection
- →Normal conditions: PODs receive their standard percentages
- →Under pressure: Revenue redirects to Settlement Pledge
- →Recovery: Once refilled, normal distribution resumes
- →No human intervention required—it's all in the code