Posting the below for feedback & comments.
dAPI Team Proposal #1, November 2022 – January 2023 (Cycle 9)
Team: dAPI Team
Operations cycle: #1
Period: 1 November 2022 – 31 January 2023 (3-months)
Amount: 158,850 USDC
Destination: Gnosis Safe (Multi-sig wallet)
Address: 0xbBbd583e6660dF247E13E7C99Ee71c54271407e6
signers:
Ugur - eth:0x62B8E7CD3bCb904a0335Cf4b1E8D10013b5bEFca
Aaron - eth:0xc5cC23c594B54FBA391Bd4E9604C803d17066dF1
Santiago - eth:0x918350a01A4C259FBCc94c6Fb2ca49A3753BDb86
2/3 Multisig
Scope
The dAPI team consists of members formerly part of the Core technical team. Due to the various areas that are being developed simultaneously and the size that the core technical team grew to in recent months (as well as the whitepaper being considered near ‘complete’), we have decided that it was time to split into specialized teams. The purpose of this team is to deliver dAPIs, in single and aggregated form, that are quantifiably secure and capture value from this endeavour for API3 and its stakeholders.
There are different moving parts that influence the final product that we want to put out, which brings changes to the things that we want and need to develop. Some of these are, for instance, the recent BYOG development as well as our approach to Oracle Extractable Value (OEV). Hence, it is important to explain what vision we’re working towards. The article ‘Monetizing Data Feeds’ that was released today lays out the endgame and this proposal together with successive ones are going to work towards making it reality.
The endgame can be split up into four phases, however they’re all being worked on simultaneously and alongside other teams. For instance, the core technical team is going to be mainly responsible for the coverage claims contracts, Vacuumlabs helps with the frontend for the API3 Market as well as OEV and @erich from operations will consult us on legal work. A lot of the deliverables are also interconnected, which means that partial delays in e.g., Phase 4 can impact how fast we can roll out Phase 1.
The completion of a phase is synonymous with a ‘launch’, meaning that we’ll incrementally reach the endgame. While I will be reporting on the development within phases in my monthly reports, the focus of development as well as reporting will be on delivering on the phases sequentially. As such, our deliverables for this cycle will be focused on Phase 1. This does however not mean that each cycle is synonymous for the completion of one phase.
Deliverables (Cycle #9 )
The BYOG article introduced how the API3 ecosystem will be able to expand onto numerous chains and make data feeds available with as little overhead as possible. The BYOG data feeds are already deployed on various testnets and we’ve been told that their availability on mainnets is just around the corner. One of the core things we want to work towards with for that is to adjust the API3 Market to find, access and fund these data feeds more easily.
The dAPI team is going to create dAPIs out of all the BYOG data feeds, allow potential users to locate them on the API3 Market as well as fund their respective sponsor wallets directly through the market as well. In addition, we will be working towards displaying informational material, such as the balance of a sponsor wallet, the average gas costs as well as an estimation for how long we expect the funds to keep the dAPI running. Overall, this work is an acknowledgement of the BYOG work, which gives it a little brush up for UX as well as the official API3 stamp.
In addition to BYOG changes to the market, additional contract development is going to be needed, which will mostly be handled by @bbenligiray. The dAPIServer contracts need to be adjusted to reflect our decision to remove whitelisting as well as incorporate the relevant parts for OEV.
Another area of contract development is going to be user proxy contracts. It is going to be a requirement to read dAPIs from a dedicated proxy contract, since this contract will a) make OEV possible to be redirected to dApps and b) is integral to the way service coverage will function. These contracts will also need to be deployed in a convenient way, which is why the flow will be incorporated into the API3 Market. For the endgame, this feature will allow users to find dAPIs, buy decentralization and coverage, as well as deploy necessary contracts all in one place.
dAPI Team Budget
| Amount (USDC) | |
|---|---|
| Grants | 151,275 |
| Expenses | 7,575 (~5%) |
| Total | 158,850 |
Team and Grants
| Team member | Role | Basis | Monthly Grant (USDC) |
|---|---|---|---|
| *Ugur | Team Lead & Product Owner | FT | 4,375.00 |
| *Aaron | Team Lead & Developer | FT | 8,750.00 |
| *Santiago | Team Lead & Developer | FT | 8,750.00 |
| Vekil | Developer | FT | 8,750.00 |
| Jiri | Product Owner | FT | 10,000.00 |
| Ashar** | Developer | FT | 9,800.00** |
*The destination will be a multi-signature wallet address managed by Ugur, Aaron & Santiago.
** US based contributor (12% extra liabilities)
Expenses
In theory, the expenses of this team should be negligable, which is why we’re keeping it at 5% of the grants as a “buffer”. The core technical team will cover most of our technical as well as design needs. With Vacuumlabs also creating their own proposal they no longer count as an expense. There can be unforseen expenses such as subscriptions (e.g. Miro last cycle) as well as potential travel (e.g. conferences or talks) that we’d like to have the funds available to cover if necessary. Finally, there will be expenses in the form of on-chain transactions for disbursing grants payments and such as creating proposals, which will be reimbursed. Transaction IDs will be retained for these and produced at the end of the cycle.
Any unspent amount will roll over to the next cycle. A supplementary proposal will be made if the team foresees any larger-than-estimated number of expenses.
Explanation of Proposal Parameters:
Target contract address is the USDC token contract address, which is 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48
Target contract signature: transfer (address, uint256). This is the function to call on the target contract, which triggers a transfer of USDC tokens.
The parameters stated include the address these USDC are to be sent to, which should match the proposal address, followed by the number of USDC. USDC has 6 decimal places, and solidity is unable to deal with decimal places - hence we add 6 zeros after the proposed USDC number. The number of decimal places can be verified on the USDC contract page of Etherscan - $1.00 | USD Coin (USDC) Token Tracker | Etherscan