JBP-519: Fund Juicebox frontend development

Synopsis

This proposal encapsulates all ongoing frontend development costs for Juicebox. It includes the continued integration of the Juicebox V4 (omnichain) contracts on juicebox.money (JBM), and the continued maintenance of core JBM.

Motivation

JuiceboxDAO needs frontend developers to maintain juicebox.money, and to complete work on the Juicebox V4 integration.

Since being funded in Oct 2023, the #protocol team has been hard at work on Bananapus, a.k.a "The Juicebox V4 Contracts", and the contracts are nearing completion.

Aeolian and JohnnyD, in accordance with their previous V4 proposal, have made great progress in the integration. We've achieved feature parity with V2/V3 frontend minus integration with the NFT contracts. We are proposing to continue this effort, while also committing to maintaining of the rest of JBM (V1/V2/V3). To accommodate the greater load, we are proposing to add an extra developer to this team in Wraeth.

Aeolian, Wraeth and Johnny D, as key developers behind the V2/V3 Juicebox contracts integration on juicebox.money and all other frontend work over the last 2 years, understand the depth of the task, and are more than capable of shipping a solid V4 integration in the proposed period.

Specification

US$14.7k per cycle (after fees) for 9 cycles to Juicebox project #609.

Rationale

In the V4 Frontend Proposal, we outlined a 3-phase implementation plan. We have completed 95% of Phase 1 (feature parity with V2/V3 on Mainnet minus NFT rewards), and most of Phase 2.

In this proposal period, we will:

1. Complete feature parity by integrating the NFT rewards contracts with the V4 interface.
2. Complete Phase 2 - ability to launch projects on various chains outside Mainnet/Sepolia, including Arbitrum, Optimism and Polygon, and support routing for such projects.
3. Move to Phase 3 - unleash the full omnichain potential of the V4 contracts:
   • Creation of a single project across multiple chains
   • Ability to operate such project across multiple chains, including seamless flow of funds between the projects’ various treasuries for token holders, and reconfiguring the project across multiple chains for project owners. We will work closely with the contract crew to understand the nuances of the capabilities and limitations of the V4 contracts to build a UI that brings their vision to life.

Phase 2 technical implementation plan:

1. Create 'aggregator' API endpoints to aggregate subgraph queries across chains (e.g. build one endpoint to get all JB projects across chains) DONE ✅
2. Add support to L2 routing (e.g. “/v4/p/arbitrum/69”) DONE ✅
3. Add ability to 'hotswap' subgraph URLs based on the given chain DONE ✅

Phase 3 design/technical implementation plan:

1. Design and build a chain selector in the create flow.
2. Design and build a settings page that allows project owners to configure their project across multiple chains.
3. Design and build a bridging UI into the project page to support project token holders accessing their tokens across all the project’s treasuries.

Risks

- We may discover the feasibility to be more complicated than anticipated. - Further changes in contracts may result in drawn out frontend development times.

Timeline

ASAP, ending in 9 cycles.

--- nance-actions
- type: Payout
  uuid: 3c024fae02014b1fae1ebc7cbf1dcaac
  payload:
    amount: "15075"
    type: project
    project: 609
    address: "0xAF28bcB48C40dBC86f52D459A6562F658fc94B1e"
  governanceCycles:
    - 87
    - 88
    - 89
    - 90
    - 91
    - 92
    - 93
    - 94
    - 95
  pollRequired: false