FHE Engine Upgrade v0.5.0 — April 27, 13:00-16:00 UTC. Read migration guide →
6. Economic Model6.3 Protocol Treasury (60%)

6.3. 60% Protocol Treasury

The Protocol Treasury represents the dominant allocation within the Fhenix-FairMarket economic structure. Receiving 60% of the net fee distribution (which itself constitutes 60% of the total 0.3% success fee remainder), the Treasury serves as the financial backbone for the protocol’s long-term sustainability, security upgrades, and decentralized governance.

By strictly enforcing a deterministic routing mechanism with a 48-hour Timelock and 5-of-9 Multisig control, the protocol ensures that Treasury funds are utilized transparently for the benefit of the ecosystem, immune to unilateral extraction or discretionary mismanagement.

Core Allocation Mechanics

The Treasury is funded exclusively through the success of auctions. If an auction is cancelled, voided, or fails, the Treasury receives zero revenue from that event.

ParameterSpecification
Funding SourceNet Fee Distribution (Remainder of 0.3% Success Fee after Keeper Bounty).
Allocation Rate60% of the Net Fee (equivalent to 0.18% of the winning bid).
Distribution TriggerAtomic split executed during the submitResolution() or settlement phase.
Access Control5-of-9 Multisig Governance Council with a mandatory 48-hour Timelock.
Override PolicyStrictly Prohibited. No onlyOwner function can arbitrarily drain or alter the Treasury allocation ratio without a governance vote.

Economic Flow Example

For an auction with a winning bid of 100 ETH:

  1. Success Fee (0.5%): 0.5 ETH collected.
  2. Keeper Bounty (0.2%): 0.2 ETH paid to the executor.
  3. Net Fee: 0.3 ETH remains for distribution.
  4. Protocol Treasury (60% of Net): Receives 0.18 ETH. (The remaining 0.12 ETH is split among Insurance, Grants, and Bug Bounties).

️ Technical Implementation

1. Deterministic Routing (TreasuryRouter.sol)

The Treasury allocation is mathematically enforced at the smart contract level using safe integer arithmetic to prevent precision loss or manipulation.

// Conceptual Treasury Routing Logic
function _allocateNetFees(uint256 netFeeAmount) internal {
 require(netFeeAmount > 0, "No fees to allocate");
 
 // Treasury receives 60%
 // Calculation: (netFee * 60) / 100
 uint256 treasuryShare = (netFeeAmount * 60) / 100;
 
 // Route to Treasury Vault (Multisig Controlled)
 treasuryVault.deposit(treasuryShare);
 
 emit TreasuryAllocation(treasuryShare, block.timestamp);
}

2. Governance & Timelock Enforcement

To prevent immediate extraction of funds in the event of a compromised key, all Treasury withdrawals or contract upgrades pass through a Timelock Controller.

// Governance Timelock Configuration
uint256 constant MIN_DELAY = 2 days; // 48 Hours
uint256 constant MAX_DELAY = 14 days;
 
function queueWithdrawal(address target, uint256 value, bytes calldata data, uint256 executeDelay) external onlyGovernance {
 require(executeDelay >= MIN_DELAY, "Delay too short");
 timelock.queueTransaction(target, value, data, executeDelay);
}

️ Strategic Funding Pillars

The Treasury is structured to support three critical operational areas, as defined in the Ethics Charter and Governance Model:

PillarUsageImpact
Continuous DevelopmentCore protocol upgrades, CoFHE integration improvements, and new feature implementation (e.g., Vickrey optimizations).Ensures the protocol remains technically superior and gas-efficient.
Infrastructure MaintenanceSubsidizing FHEOS node operations, Keeper network incentives (during low-volume periods), and cloud monitoring costs.Guarantees 99.9% uptime and decentralized liveness.
Security & AuditsFunding recurring external audits (e.g., CertiK, OpenZeppelin), bug bounty payouts, and insurance premiums (Nexus Mutual).Protects user funds against theoretical vulnerabilities and exploits.

️ Security & Integrity Guarantees

  1. No Discretionary Overrides: The 60% allocation is hardcoded. Even the Multisig cannot unilaterally change the percentage to 100% without a transparent governance proposal and community execution.
  2. Multisig Redundancy: The 9-member council includes diverse stakeholders (Core Devs, Security Auditors, Community Reps, AVS Operators). A 5-of-9 threshold ensures no single entity can move funds.
  3. Event Transparency: Every deposit into the Treasury emits an indexed TreasuryAllocation event, allowing the community and DAO dashboards to track revenue accumulation in real-time.
  4. Emergency Isolation: In the event of a critical protocol vulnerability (EmergencyHalt), Treasury funds can be deployed via governance to reimburse affected users, prioritizing Funds Over Privacy.

Audit Gate Compliance (P1 - Pre-Mainnet)

Progression to Mainnet deployment requires the Treasury module to pass the following verification gates:

  • [] Deterministic Math Verification: Unit tests confirm the calculation (netFee * 60) / 100 is precise and handles dust correctly.
  • [] Multisig Ownership: owner() of the Treasury contract points to the Gnosis Safe (Multisig) address, not an EOA.
  • [] Timelock Active: Withdrawal functions revert if called directly without a queued proposal and 48h delay.
  • [] No Admin Drain: Static analysis (Slither) confirms no function allows a single address to sweep the Treasury balance.
  • [] Event Emission: TreasuryAllocation event is triggered on every successful settlement.

Next Steps

6.2 Keeper Bounty (0.2%)6.4 Insurance Fund (20%)