Mission 02: Proxy Fee Template V2

[jeremie-olivier]

Board item: Proxy Fee Template
Status: Ideas | Priority: P0
Reward: $1,100 USDC + iBox token (split across sub-bounties)
Target: Solidity / full-stack developers
Chain: Intuition Network (mainnet: 1155, testnet: 13579)

Context

The Fee-Proxy-Template is a smart contract proxy for the Intuition MultiVault that intercepts deposits and collects fees. V1 is complete — a working proxy with fixed + percentage-based deposit fees, admin controls, and batch operations.

V2 is a set of improvements split into independent sub-bounties.

Sub-Bounties

Bounty 2A: Fix Issue #1 — $200 USDC

• Investigate and fix the reported issue
• Add/update tests covering the fix
• PR merged to main

Bounty 2B: Upgradable Proxy — $100 USDC

• Implement an upgradable proxy pattern using EIP-7936
• Ensure admin can upgrade the contract logic while preserving state
• Migration path from current non-upgradable deployment
• Tests for upgrade scenarios

Bounty 2C: Withdraw Function — $200 USDC

• Add a withdraw function for the fee recipient
• Remove the current fee forwarding mechanism (fees accumulate in contract instead of auto-forwarding)
• Admin controls for withdrawal
• Tests covering withdraw scenarios and edge cases

Bounty 2D: Factory Webapp — $300 USDC

• Build a webapp to deploy the proxy contract in one click via a factory contract
• Factory contract should use UUPS (Universal Upgradeable Proxy Standard) proxy pattern
• Factory pattern similar to Uniswap V2 Factory for LP creation
• Users can configure their fee parameters and deploy their own proxy instance
• UI for managing deployed proxies
• Deploy on both Intuition mainnet (1155) and testnet (13579)
• Include documentation on how the factory webapp works

Bounty 2E: Article & Social — $100 USDC

• Write an article explaining the V2 changes and how to use the template
• Create an X post thread announcing the improvements
• Include technical walkthrough and usage examples

Acceptance Criteria (per bounty)

• Code reviewed and PR merged
• Tests passing
• Intuition Team validation required before payout

Repo: https://github.com/intuition-box/Fee-Proxy-Template

[y4motion]

Hi @jeremie-olivier

We've submitted a PR covering all V2 sub-bounties (2A–2E): 👉 #3

Quick summary of what's included:

2A – receiver == msg.sender enforcement on all 4 deposit functions
2B – Full UUPS upgradeable pattern via OpenZeppelin v5 (Initializable + UUPSUpgradeable)
2C – Fee accumulation in contract + admin-gated withdrawFees / withdrawAllFees
2D –

FeeProxyFactory.sol
(ERC1967Proxy) + Next.js 16 webapp (ethers v6) with one-click deployment
2E – Technical walkthrough in webapp/README.md + X thread draft
All 37 tests pass. No mocks. Static analysis (Slither) — zero high/medium findings.

Happy to take on additional bounties or make any corrections. Feel free to reach out directly on Telegram: https://t.me/Easternw11nd

[Jay0xx]

+All 5 V2 Bounties Complete
+
+PR: #4
+
+2A — Fix Receiver Validation (Issue #1) — $200
+Added receiver == msg.sender enforcement on deposit(), createAtoms(), createTriples(), and depositBatch(). Reverts with ReceiverMismatch if violated. Prevents frontend fee theft.
+
+2B — UUPS Upgradeable Proxy — $100
+Implemented OpenZeppelin v5 UUPS pattern with _disableInitializers(), initialize(), _authorizeUpgrade() gated by onlyWhitelistedAdmin. Full migration path from V1.
+
+2C — Fee Accumulation + Admin Withdraw — $200
+Removed auto-forward _transferFee() due to gas griefing vector. Fees now accumulate in the proxy. Added withdrawFees() and withdrawAllFees(), both admin-gated.
+
+2D — Factory Contract + Webapp — $300
+FeeProxyFactory.sol deploys UUPS proxies via ERC1967Proxy, tracks proxies per deployer. Webapp is Next.js 16 + ethers v6 with wallet connection, Intuition Mainnet/Testnet detection, configurable fee params, one-click deploy, explorer links, and deployed proxy list.
+
+2E — Article + Social — $100
+Full technical article: ARTICLE.md
+X post: https://x.com/Afkd3vil/status/2049526892412158406
+
+Tests: 41/41 passing (36 proxy + 5 factory, zero mocks)
+
+V1 vs V2:
+Solidity 0.8.21 -> 0.8.24
+Framework Hardhat -> Foundry
+Proxy None -> UUPS (ERC1967)
+Receiver check None -> receiver == msg.sender
+Fees Auto-forward -> Accumulate + admin withdraw
+Factory None -> FeeProxyFactory.sol
+Webapp None -> Next.js 16 + ethers v6
+Tests 37 -> 41

[Asobu01]

I can take #2.
For "Mission 02: Proxy Fee Template V2", I will start by reproducing the user-facing issue and narrowing it to the specific view/component.
Target: draft PR in ~8h.
I can post a reproducible checklist/log snippet in ~30 minutes so you can verify execution speed before the full PR.
Deliverables: minimal UI fix aligned with current UX; quick before/after validation notes; PR with clear change summary.
@Asobu01

[Asobu01]

Quick follow-up on intuition-box/Fee-Proxy-Template#2. I am still ready to start immediately and can post the first repro/checklist note before the draft PR if helpful. If you want me on this one, I can begin now. (@Asobu01)

[y4motion]

Hey @jeremie-olivier — just following up on our PR #3, submitted on April 23.

It covers all five V2 sub-bounties (2A–2E) with 41 passing tests and a clean Slither audit. We also left a review request comment on the PR on April 25.

For clarity on the timeline:

• PR feat(v2): UUPS Upgradeable Proxy, Receiver Fix, Fee Accumulation & Factory Webapp #3 (y4motion): April 23 — receiver fix, UUPS proxy, fee accumulation, factory contract + webapp, article
• PR feat(v2): UUPS Upgradeable Proxy, Receiver Enforcement, Fee Accumulation & Factory Webapp #4 (Jay0xx): April 29 — submitted 6 days later with identical architecture, function names (withdrawFees, withdrawAllFees, ReceiverMismatch), and implementation details

Happy to address any feedback or make adjustments. Let us know how you'd like to proceed.

[giantcoconut]

I would like to apply for Mission 02: Proxy Fee Template V2.

I am a full-stack builder, and I have spent time understanding this repo, the bounty requirements, and the receiver bug. My approach would be review-focused: keep the current Hardhat/TypeScript stack, make the changes easy to review, and confirm the upgradeability expectations before implementing the more sensitive parts.

My current understanding of the mission:

Fix the unsafe receiver flow across deposit, createAtoms, createTriples, and depositBatch.
Change fees from auto-forwarding to accumulating in the proxy contract.
Add safe withdrawal controls for accumulated fees.
Handle upgradeability properly, especially because the bounty mentions EIP/ERC-7936 and not just generic UUPS.
Build a factory/webapp flow for deploying and managing configured proxy instances on Intuition mainnet 1155 and testnet 13579.
Document the real migration path from the current non-upgradeable V1.
From reviewing the mission requirements, I think the implementation should especially account for:

preserving the repo's existing Hardhat setup where possible,
tracking fees explicitly with accruedFees instead of treating all contract balance as fees,
adding real upgrade/state-preservation tests,
clarifying whether the factory itself needs to be UUPS-upgradeable,
avoiding hardcoded local-only factory addresses in the webapp,
documenting the non-upgradeable V1 migration path accurately.
If selected, I would start by sharing a short implementation plan for confirmation, especially around ERC-7936/UUPS and factory upgradeability, then implement in focused steps with tests.

Proof/context:

I have already reviewed the repo structure and mission requirements closely enough to understand the main risks before starting.
I can contribute strongly on the full-stack/webapp side while working carefully through the Solidity changes with tests and review discipline.

[Wieedze]

Hello,

I am Max, a junior developer strongly interested in Web3 applications and eager to learn more about Solidity. I have been building applications on top of the Intuition Protocol full-time for the past year, and I am part of the Sofia team, a Chrome extension built on top of the Intuition Protocol.

At Sofia, we are currently using a proxy contract that I built six months ago to demonstrate the usage of our dApp. It was not the best proxy architecture possible, but it served as both a proof of concept and a proof of usage for our application.

Now, with all this background experience and these real-world use cases, I have a much clearer vision of what a proxy factory designed specifically for builders could look like. I am very interested in this mission, both because we need this new version for the evolution of our application and, more personally, because I want to involve myself in building tools that address the community’s needs.

This new proxy could become a real centerpiece for builders, allowing them to easily display metrics, prove application usage, and engage with different teams to secure grants or attract investors. At the same time, it would open the door for builders to experiment with economic models in a permissionless way and even create applications that abstract the Intuition layer entirely.

I have reviewed all the mission requirements, and I am confident that I can deliver the specifications within a matter of days.

[Tony8265]

Hi, I can take Bounty 2C (Withdraw Function) first.

Plan:

• inspect the current fee forwarding flow
• change fees to accumulate in the proxy contract
• add an admin/fee-recipient withdrawal path
• add tests for withdraw, access control, zero balance, and edge cases
• submit a focused PR for review

GitHub: Tony8265
Payout address: 0xdF7E9D6640BEcA1239276D4aA72E53321619E1c1