6.5. 15% Developer Grants

The Developer Grants allocation represents the protocol’s commitment to sustainable, community-driven innovation. Receiving 15% of the net fee distribution (equivalent to 0.045% of the winning bid), this fund is exclusively dedicated to rewarding external contributors who propose, implement, or validate improvements to the Fhenix-FairMarket ecosystem.

By decentralizing development incentives beyond the core team, the protocol ensures long-term resilience, cryptographic advancement, and adaptive evolution in response to emerging threats or opportunities in the sealed-bid auction domain.

Core Allocation Mechanics

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. Developer Grants (15% of Net): Receives 0.045 ETH. (The remaining 0.255 ETH is split among Treasury, Insurance, and Bug Bounty).

️ Technical Implementation

1. Deterministic Routing (GrantsRouter.sol)

The Grants allocation is mathematically enforced at the smart contract level, ensuring no discretionary overrides.

// Conceptual Grants Routing Logic
function _allocateNetFees(uint256 netFeeAmount) internal {
 require(netFeeAmount > 0, "No fees to allocate");
 
 // Grants Fund receives 15%
 // Calculation: (netFee * 15) / 100
 uint256 grantsShare = (netFeeAmount * 15) / 100;
 
 // Route to Grants Vault (Governance Controlled)
 grantsVault.deposit(grantsShare);
 
 emit GrantsAllocation(grantsShare, block.timestamp);
}

2. Governance-Gated Disbursement (GrantsGovernance.sol)

Funds are not distributed automatically. Each grant requires a formal proposal, community review, and multisig execution.

// Pseudo-code: Grants Proposal & Execution Flow
struct GrantProposal {
 address recipient;
 uint256 amount;
 string description; // IPFS hash of detailed proposal
 uint256 submittedAt;
 bool executed;
 mapping(address => bool) hasVoted;
}
 
function submitGrantProposal(
 address recipient,
 uint256 amount,
 string calldata descriptionIpfsHash
) external onlyGovernanceMember {
 require(amount <= grantsVault.balance(), "Insufficient grants balance");
 
 uint256 proposalId = proposals.length;
 proposals.push(GrantProposal({
 recipient: recipient,
 amount: amount,
 description: descriptionIpfsHash,
 submittedAt: block.timestamp,
 executed: false
 }));
 
 emit GrantProposalSubmitted(proposalId, recipient, amount);
}
 
function executeGrant(uint256 proposalId) external onlyGovernance {
 GrantProposal storage proposal = proposals[proposalId];
 require(!proposal.executed, "Already executed");
 require(block.timestamp >= proposal.submittedAt + 48 hours, "Timelock not expired");
 
 proposal.executed = true;
 (bool success, ) = proposal.recipient.call{value: proposal.amount}("");
 require(success, "Grant transfer failed");
 
 emit GrantExecuted(proposalId, proposal.recipient, proposal.amount);
}

3. Transparency & Accountability Measures

Every grant allocation is publicly auditable via on-chain events and off-chain documentation:

event GrantProposalSubmitted(uint256 indexed proposalId, address indexed recipient, uint256 amount);
event GrantExecuted(uint256 indexed proposalId, address indexed recipient, uint256 amount);
event GrantRejected(uint256 indexed proposalId, string reason);

Grants Lifecycle & Governance Flow

Eligibility & Evaluation Criteria

Grants are awarded based on verifiable impact and alignment with protocol goals:

Evaluation Framework

1. Proposal Submission: Detailed scope, timeline, deliverables, and budget submitted via GitHub Discussions or dedicated portal.
2. Community Review: 7-day public comment period for feedback and refinement.
3. Governance Vote: Multisig council (5-of-9) evaluates technical merit, budget reasonableness, and alignment with roadmap.
4. Milestone-Based Disbursement: Large grants (>5 ETH) are split into tranches tied to verifiable deliverables.
5. Post-Grant Reporting: Recipients publish a summary of outcomes, code repositories, or research outputs for public audit.

️ Security & Integrity Guarantees

1. No Discretionary Overrides: The 15% allocation is hardcoded. Even the Multisig cannot unilaterally redirect grants to non-approved recipients without a governance proposal and timelock.
2. Multisig Redundancy: The 9-member council includes diverse stakeholders (Core Devs, Security Auditors, Community Reps, Academic Advisors). A 5-of-9 threshold ensures no single entity can approve grants unilaterally.
3. Event Transparency: Every proposal submission, approval, execution, or rejection emits an indexed event, enabling real-time tracking by the community and DAO dashboards.
4. Milestone Verification: Large grants require cryptographic proof of deliverable completion (e.g., merged PR, published paper, deployed tool) before subsequent tranches are released.
5. Anti-Sybil Measures: Recipient addresses are screened for prior malicious activity; grants to newly created wallets require additional identity verification via Gitcoin Passport or similar.

Audit Gate Compliance (P1 - Pre-Mainnet)

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

• [] Deterministic Math Verification: Unit tests confirm the calculation (netFee * 15) / 100 is precise and handles dust correctly.
• [] Governance Ownership: owner() of the Grants Vault points to the Governance contract, not an EOA or single multisig.
• [] Timelock Active: Grant execution 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 Grants balance.
• [] Event Emission: GrantProposalSubmitted, GrantExecuted, and GrantRejected events are triggered and indexed.
• [] Milestone Logic Tested: Unit tests verify that tranche-based grants require proof-of-deliverable before release.

Unresolved Points & Explicit Gaps

Fact vs. Analysis Distinction: The 15% allocation rate, governance-gated disbursement, and multisig access controls are verified facts from the official Whitepaper and Technical Specification. The bootstrapping strategy, evaluation metrics, and cross-chain portability are unresolved architectural gaps that require explicit definition before Mainnet deployment.

Next Steps

• Proceed to 6.6. 5% Bug Bounty to understand the Immunefi integration and vulnerability disclosure workflow.
• Review Governance & DAO Transition for the multisig-to-DAO handoff procedure and grants voting mechanics.
• Explore Contributing → Grants Program for proposal templates, eligibility guidelines, and submission portal.