[Secondary Proposal #57] Business Development Team Proposal <> API3 Cycle #10 - February 2023 - April 2023

API3 DAO BD Team Proposal

Business Development Team Proposal, February 2023 – April 2023 (Cycle 10)

Team: Business Development Team

Operations cycle: #10

Period: 1 February 2023 – 30 April 2023 (3-months)

Amount: 50,060 USDC

Destination: Gnosis Safe (Multi-sig wallet)
address 0xB6124cE91E7ba6650791Bf969F94E31e2631cE86
signers:
Dave - dav3.eth
Gio - 0x3afB3530Da3CBa4d8B278Af63872FAA80F1fC87D
Kevin - 0x676f0341FC230dD28455A5B32b28651ACC377c88
2/3 Multisig

## Scope

The Business Development team (BD) drives holistic organizational-wide value within the DAO. API3’s vision is to be the first choice in DAO-governed decentralized data oracles and data feeds for Web3. The BD team is further exploring new ways to achieve incentive-orientated decentralization and more towards DAO autonomy.

We believe OEV (Oracle Extractable Value) will be an end-game product that will change the face of DeFi and the larger Web3 ecosystem.

BD drives DAO-value, through forging partnerships, seeking synergies and creating a sales pipeline for the above described data oracle products. Customer and market feedback is further forwarded to technical teams for R&D purposes. These all translate into measurable and unmeasurable ROI from these revenues and “intangibles” or partnerships.

For the purpose of this proposal, BD’s general responsibilities encompasses these overarching responsibilities that relate to:

Sales process

  • Outreach
  • Continuous improvement of outreach processes
  • Exploring decentralization strategies

Recruitment & HR (In-line with product growth - on pause until dAPI scaling)

  • Onboarding
  • Training
  • Best practice
  • Ongoing support

Coordinate with the marketing and ecosystem sub teams

  • Help with ecosystem outreach and activities
  • General networking and on-the-ground interactions
  • Articles, blogs and content
  • Liaising with other relevant API3 sub teams
  • Attend conferences and workshops

R&D

  • Technical-side feasibility of integrations
  • Business-side feasibility assessment
  • Customer and market sentiment analysis and feedback

Internal workshops and meetings

  • Attend mandatory sub team and team meetings
  • Knowledge dissemination and internal knowledge workshops or materials

Team Movements

  • No team movements or additions.

1.BD - Enterprise & Provider Focus:

Gio has been engaging with large organizations over the last few cycles. He will continue to allocate his time developing partner and provider relationships and events, which are key for the development of dAPIs and OEV. In addition to these tasks and working alongside Dave and Kevin, he will assist in overall BD growing out the pipeline, interactions and autonomous functions for the BD mid-term vision. Gio will update us on any enterprise movements and large deal flows (some are still in progress, due to the bear market slow-down), as well as, any PoCs of Pilots when they are complete.

## Completed Deliverables (Cycle #9)

Following-through from the previous update, the alphabetical numbering is mapped and reconcilable to the previous proposal for your reference e.g. (A)-(Q) :

  • Update 1: A large market data provider (A) - status: in closed-pilot testing phase
    • We are working with a dApp to deliver this end-to-end solution with a large provider. The current dApp is nearing testnet completion, we have a few weeks of extension to finalize the testnet closed-pilot.
  • Update 2: A large financial data institution (B) – status: still engaging
    • We are meeting their team again in Q2 to discuss a more serious engagement when it comes to their data oracle strategy.
  • Update 3: A large-size crypto market data provider (H) – status: placed the interaction on hold. Will resume discussions.
  • Update 4: A large enterprise blockchain provider (I) – status: at final stages
    • We are finalizing the vendor agreement with a few legal reviews, high likelihood of success.
  • Update 5: A large-size crypto market data provider (K) – status: follow-up
  • Update 6: A large-size crypto market data provider (L) – status: in progress
    • technical testing done, moving to business discussions.
  • Update 7: A medium-size market data provider (M) – status: moving forward (Crypto, Forex and Equities) - technical testing done, moving to business discussions.
  • Update 8: A medium-size market data provider (N) – status: moving forward (Crypto, Commodities, Forex and Equities) - technical testing to still take place.
  • Update 9: A large financial data institution (O) – status: early engagement.
    • On-going rapport building.

Closed or cold interactions:

  • Update 10: A large reinsurance institution (C)– status: cold

    • Engagement has stopped due to lukewarm interaction.
  • Update 11: A large consulting house (D) – status: cold

    • Engagement has stopped due to lukewarm interaction.
  • Update 12: A medium-size crypto market data provider (E) – status: on-hold.

    • The provider security schema is currently incompatible due to OAuth security.
    • We will support this functionality further down our technical roadmap and do not want to bottleneck the dAPI/OEV launch.
    • Engagement will be on pause until we can technically support this integration.
  • Update 13: A medium-size market data provider (F) – status: cold

    • Engagement has stopped due to lukewarm interaction.
  • Update 14: A large-size market data provider (G) – status: status: cold

    • Engagement has stopped due to lukewarm interaction.
  • Update 15: A nation-state federal department (J) – status:cold

    • Engagement has stopped due to lukewarm interaction.

New engagements over the quarter:

  • Update 16: A medium-size market data provider (P) – status: moving forward (Crypto, Forex and Equities) - technical testing done, moving towards business discussions
  • Update 17: A large asset manager (Q) – status: early stage, initial discussions
    • Discussed OEV and data oracle related applications.
  • Update 18: Outreach to 20 market data providers (R) - status: follow-ups in progress

For Cycle #10, no new enterprise engagements will be prospected. Rather, the existing ones followed-up and closed. The focus will be on the providers, OEV and exploring new ways for BD to achieve greater autonomy and programmability.

## Deliverables (Cycle #10)

Gio’s goal is to close out the above interactions and provide feedback on these outcomes. In addition, to find market data providers, so that dAPIs will have better quality and robustness for their aggregation and selection.

Gio will be doing research on arranging an API or Provider focused-event in 2023/2024 to grow and strengthen our relationships with data sources.

While this is being done, Gio will assist Kevin and Dave in accomplishing OEV and driving self-funded dAPIs, QRNG’s interest and integrations.

The approach for providers is the following: gauge a provider’s interest; get access to a test API to do compatibility and calibration testing. Once the technical team is happy with these stress-test results, discuss and sign commercials and lastly, self-integrate the provider (via ChainAPI). The commercial elements include a revenue-sharing model.

Provider goals:

  • In Cycle 7, three providers were onboarded with datasets that include (Crypto, Forex, Indices,Commodities and Equities);
  • In Cycle 8, two additional partner providers were onboarded (i.e. one that only does forex) and the other provider has Crypto, Forex, Equities pairs.
  • In Cycle 9, three providers underwent technical compatibility testing and data quality, bringing this within the desired goal range of 2-3 providers for the quarter. Of the testing done (for the 8 providers), all passed our technical tests and can be used for dAPIs and OEV related products.
  • In Cycle 10, the goal is to bring providers that have passed our technical testing under letter of intents. This would involve discussing the business elements to secure the deals.
    • In addition to this, the goal would be to technically test and onboard an additional 2-3 providers for commodities and indices data so that the full coverage of asset classes is covered.

BD Autonomy Exploration

  • For the quarter, Gio, Dave and Kevin will spend some time exploring conceptual ideas around floating the BD team in a more decentralized and autonomous fashion.This will allow for a medium-term focus that aligns with the purpose of the DAO itself, decentralized-autonomous-value-creation.
  • This will lay the theoretical foundation of what can be achievable. Post this exploration, the technical team will be engaged to add this as a DAO-build priority, whether as a hybrid or as an experimental try-out.
  • If this is successful, over the next two quarters, this could be the framework for Marketing and other sub-teams prioritizing value-delivery in a decentralized and achievable way.

As testnet dAPIs are live now, and cycle 10 will involve recruiting users for them, it makes more sense to divide the blockchain side up into the two separate products, QRNG and dAPIs for the cycle 10 proposal, with both encompassing different aspects of the dapps/platform side of BD.

## 2.QRNG (listed on cycle 9 as dapps and platforms):

Dave has been spearheading the dApps and Platforms outreach. In addition to his niche, Dave will focus on general BD alongside Gio and Kevin. Furthermore, he will help drive OEV and dAPIs narrative and awareness, working closely with the Ecosystem subteam. Kevin will work closely with the dApp and Enterprise teams but will primarily focus on OEV.

## Completed QRNG Deliverables (Cycle #9)

QRNG Deployments

Cycle 9 had QRNG deployed to a total of 6 new chains - Arbitrum Nova, Aurora, BOBA’s Moonbeam, Avalanche, BNB Chain and ETH rollups, and SX Network. The connections this has helped foster with the chains will improve the ability for API3’s ecosystem subteam to deliver value with the upcoming launch of mainnet marketplace feeds, and OEV development.

QRNG Usage

QRNG total usage over this cycle is hard to give exact figures for due to not all chains being included on the monitoring yet. The original chains show a total of around 300 requests this cycle, with request numbers on the newly deployed or otherwise unmonitored chains as below:

Arbitrum Nova = ~1300

Arbitrum One (not a new deployment but not on monitoring) = 200 +

SX Network = ~120

Mainnet = 150

This gives a total of approximately 2100 requests in total over this cycle. Note that this should be considered a minimum, based on the lack of ability to include the BOBA rollups in this total, and figures being calculated 2 weeks prior to cycle end. Averaging out to 700/month represents an improvement on last cycle’s 500 requests per month

QRNG Users

The following projects have announced their usage of QRNG during this cycle. Note that it is likely more projects are using it, but we operate it as a public good so there is no need for projects to ask us to use it, or tell API3 that they are. The projects below are ones that have contacted us or tweeted about using QRNG.

Damned Pirates Society - https://twitter.com/thedpsproject/status/1552180223092969472

The Pendings - https://twitter.com/thependings/status/1611181711240347649?s=20&t=UK94JQS4Z3q8H-2oipSNqQ

NFBees - https://twitter.com/wc49358/status/1615236488400367616

Quantomons - https://quantumon.xyz/

## Deliverables (Cycle #10)

Although QRNG is a public good, we still believe that it helps our BD and ecosystem teams, and is still important to support. We believe QRNG acts as an important tool for awareness of API3 generally, and familiarizing developers with the first party oracles concept, as well as the request-response protocol and the API3 ecosystem generally. For cycle 10 the BD team will be paying commission, included in this proposal budget, for BD work leading to successful QRNG dapp integrations, which will also be a deliverable for the next proposal.

The BD team believe that through expanding QRNG to more chains, developer awareness of API3 will increase, and plan to help the ecosystem team deploy to currently unsupported chains where possible. The benefit of supporting additional chains will be assessed during this next cycle, and extra deployments conducted where developer resources are available, and the benefits felt worth their allocation.

For cycle 10 the BD team will be paying commission, included in this proposal budget, for BD work leading to successful self-funded dapp integrations, which will also be a deliverable for the next proposal.

There will be three tiers of commission, based on TVL of the dapp using the feed/s:

  • <$5m TVL - $1k per integration

  • 5-$15m TVL - $1.5k per integration

  • '>$15m TVL - $2k per integration

Tiers are based on TVL because, until OEV figures are available, it is expected to be the most correlated value to extractable OEV that can be easily determined. This is intended for BD team members working on dapp outreach, but will be available to other DAO members who can deliver integrations on a discretionary basis.

3. BD – OEV and dAPIs

Completed Deliverables from Last Cycle

Sales Planning

OEV is going to have a considerably different value proposition to different entities, whether that be a chain, a dApp, someone who is paying for sponsorship, or someone who plans on using a free proxy. We created an ordered plan of outreach to achieve the greatest level of adoption.

CRM planning

We went through multiple demos and identified a workable CRM that will be suitable for the unique outreach style that we perform. Having a common dashboard where Business Development can have a unified view of deals to distribute and collaborate on will be critical for efficiency.

Basic Sales Collateral

Work has been put into creating basic templates that show various levels of OEV achieved based on various levels of liquidation/volume. Going through this process has illuminated the breadth of potential returns and will help educate dApps on how they can benefit from our product.

Commission Survey/Structure

A survey of 5 different SaaS sales departments was performed to help inform a commission structure for OEV/general outreach. From there, a plan was drafted to create a sustainable structure for Business Development. Aspects such as: Team Structure, Self-Managed Feeds Outreach, API3-Managed Feeds Outreach, Proxy Feed Sign-Up, Annual OEV Generated Compensation, KPIs, Account Management and Referral Structure were considered.

The scope of this discussion has expanded and will continue into the next phase. Along with defining BD compensation, we’ll explore appropriate compensation for data providers and the DAO as a whole to ensure cohesion and scalability. Some initial discussions centered around hypothetical numbers and ambiguous requirements. Providing a clearer view of what an adoption curve/income would look like, along with an updated proposal will help align all parties.

Soft Outreach

Kevin performed a speaking engagement at UC Berkeley, and started initial meetings with a few dApps for self-funded feeds. Applications have been made to speak at a number of conferences taking place during the next cycle.

Initial Outline for Grant Requests from Chains

A good way to get a foot in the door with chains is to go through a grant writing process. Getting a chain to subsidize feeds will have the desired effect of making the feeds free for anyone who chooses to use a proxy and will make the decision to switch to API3 easier. If we prove out that $X is going back into a particular ecosystem due to our product, we can eventually evolve the grant conversations into more formalized business relationships and explore monetization that way after we deliver value to their ecosystem. Some grant request templates are fairly in-depth and work on our submissions has been started.

Ecosystem material

Kevin helped edit/draft various pieces of Ecosystem collateral related to OEV.

Upcoming Phase: (BYOG Launch (Jan/Feb) to March)

Comments:

The first product that will be ready is Self-Managed Feeds from BYOG. We plan to use these as a way to rekindle relationships with dApps who we weren’t able to previously deliver for, and to continue building a track-record of successful adoption. Through BYOG we can entertain unique data requests, and eventually usher them along our pipeline to our later managed feeds/OEV products.

Action Items:

  • Qualify and distribute dApps to target. (the market will look very different than what it was 6 months ago)

  • Pitch to every ecosystem that doesn’t yet have feeds available, as well as projects that have outstanding LOIs for unique feeds.

  • Finish grant applications so we can present our requests upon the successful release of managed feeds.

  • Identify contract terms we would like to push for managed feeds and start discussions around pricing.

  • Work with the Ecosystem team to make a full pitch on how we will expose the feeds to dApps within an ecosystem if a chain would become a sponsor.

  • Finalize a compensation plan that makes sense for the DAO, BD, and Data Providers alike.

  • Contribute to foundational work on what it would look like to further decentralize the business development component of the DAO and identify milestones where it would make sense to introduce more programmability into our processes.

Next Phase: Managed Feeds Launch (March-June)

Comments:

While BYOG can be great in enabling unique feeds that haven’t been available from other sources, it is unlikely that a dApp will move current feeds in use, over to that product. Managed Feeds will be a step closer to OEV which we expect to be more of a driver for a dApp making a switch and one where we can begin to make a more aggressive pitch to all dApps.

In order to make feeds accessible, engaging Base Feed sponsors will be critical to growing the greater ecosystem. On expensive networks such as ETH Mainnet, there are scenarios where the gas cost of feeds may outweigh the expected OEV proceeds for a dApp, making it unreasonable for a dApp to use us if they have to shoulder 100% of that cost. Any feed we can get an initial sponsor for will allow us to circulate it to others for free and to generate a maximum amount of OEV and adoption. This period is focused on setting that foundation.

Action Items:

  • Grow any self-funded feeds into API3-managed feeds if possible

  • Submit grant requests and open dialogue with chains.

  • Create sales packages that enable an economy of scale that will enable us to lessen the gas burden to dApps on chains where we can’t get support/subsidies (and maybe for chains where we do, regardless)

  • When we get base feeds set up, it may make sense to start targeting dApps within that chain immediately after, rather than pitching a different chain all together. As long as adoption and outreach are occurring, that’s fine. Some ecosystems should be a higher priority than others.

  • Begin wider sales campaign to all dApps in preparation of OEV launch

Business Development Budget

Amount (USDC)
Grants 19,125
New BD Grants (Paused) 0
^ Success Commissions 20,000
^ Total Expenses 14,100
Ethereum Enterprise Alliance Membership 3,000
Conferences 10,000
LinkedIn & Hunter.io 1,100
Grant Sub Total 53,225
Total Credit Roll over from last cycle -8,165
** Kevin’s one-off Grant 5,000
Grant Total (Less Roll-over) 50,060

Team and Grants

The team is composed of Business Development personnel.

Team member Role Focus Monthly Grant (USDC)
*Dave Team Lead & Business Developer dApps & Platforms 2,000.00
*Gio Team Lead & Business Developer Enterprise & Providers 4,375.00
*Kevin Team Lead & Business Developer OEV and dAPIs g2m Commission based # ** Once off payment for delay in token vesting schedule
  • The destination will be a multi-signature wallet address managed by Dave, Gio & Kevin.

Requested compensation levels are as per the API3 DAO Compensation Guidelines

** There was a delay with Kevin’s vested token allocation, for this reason the BD team compensated Kevin a $5,000 once-off grant for the delay (i.e. since November 2022) to aid him in his expenses for the 3-month period.

'# Kevin is due to receive his agreed upon token vesting to allow participation in governance

Success commissions will be paid to eligible BDs for delivering successful and working self-funded dAPIs and QRNG integrations.This will come from the expense and success commission allocation. We project 5-10 integrations over the cycle, with commissions between $1,000 (Low TVL dApps / QRNG ), $1,500 for medium grade dApps, and $2,000 (medium/high-grade dApps).

The dApp ‘grading’ definition for the context of commissions payable:

TVL<5m = small, <15m = medium, >15m = high

Expenses

The team has suspended the recruiting of new business developers on a contractor basis. The success commissions still remain in effect in order to highlight the non-performers from the skillful hunters. Thus, there is a success commission allocation for BDs that conclude an end-to-end new dApp integration of the API3 self-funded dAPIs and the QRNG service.

The business development team will also be attending events as indicated as critical to drive new partnerships and ecosystem growth. Conferences and events that fall outside of large Marketing team sponsored events will be funded by the business development teams grant budget as per the Travel Reimbursement schedule.

Dave and Kevin (tentative) will be attending the ETH Denver Developer Conference in March and Gio will be at the Consensus Austin Conference in April.

In addition to the conference expenses, the team will potentially need access to tools to help streamline the BD pipeline. Some specific examples (not an exhaustive list) are:

  • CRM Software
  • HubSpot
  • Docsend
  • LinkedIn Premium (Prospecting or Job Posting)
  • Hunter.io (Prospecting)

When tools or features are chosen, receipts will be kept for production at the end of the cycle. Any remaining expenses will be rolled over to the next cycle.

The final category of expenses is for on-chain transactions in disbursing grants payments and such as creating proposals in other DAOs. 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 tied to performance or of BD outcomes generated.

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
1 Like

The proposal is up for vote and can be seen here: https://api3.eth.link/#/governance/secondary-57

Hey Gio (and BD team) - thanks for putting the detail into the proposal. Apologies for the slow engagement, I took a first read over the weekend. Have a few points that I want to ensure we’re aligned on:

Action Item: Pitch to every ecosystem that doesn’t yet have feeds available, as well as projects that have outstanding LOIs for unique feeds.

With relatively lean resources for the coming cycle, the eco team needs to ensure we support the developer experience and learning process whilst driving developer awareness for the mentioned launch. I think in general we need to focus on the task at hand and ensure we deliver the above to the 13 chains dAPIs will be accessible on.

Within this, there is a range of ways we can increase developer awareness without an upfront chain integration. As such for this coming cycle deployments to new chains are not able to be a priority.

Cycle 9 had QRNG deployed to a total of 6 new chains - Arbitrum Nova, Aurora, BOBA’s Moonbeam, Avalanche, BNB Chain and ETH rollups, and SX Network. The connections this has helped foster with the chains will improve the ability of API3’s ecosystem subteam to deliver value with the upcoming launch of mainnet marketplace feeds, and OEV development.

I’m not aware of any plans to be launching dAPIs or OEV to these chains so can’t immediately see how this ties into the launch of self-funded feeds/marketplace. Also, any efforts to deploy would be led by the dAPI team. Unsure if I’ve misinterpreted this or overlooked key points, but want to make sure expectations are aligned here.

Again thanks for putting this together - looking forward to the ecosystem and BD team working together the next cycle and great work on the enterprise side, you’ve been killing it there.

Just wanna put this out there since it has been brought to my attention.
Please do not plan with deployments of dAPIs on any >additional< chains. I think my stance on this has been very clear from the get go and the dAPI team will not be promising or delivering dAPIs on any other networks than the mentioned 13 for the foreseeable future.

1 Like

@UgurMersin - yes, we would never promise this to chains with a defined timeline (other than after consulting with the dAPI team of course).

@KenKarv - You seem to be misunderstanding the proposal. Scoping out additional chains for QRNG deployments is separate to the second quote. “Pitching to ecosystems that do not have feeds available” refers to chains within the 13 that currently lack data feeds partly or entirely. Fun fact, after the self funded feeds are live on the 13 mainnets, we will be the top data feed provider (in pair availability) on every chain other than Polygon and Mainnet ETH. This should give us plenty of opportunities to meet currently unmet needs

Re:

I’m not aware of any plans to be launching dAPIs or OEV to these chains so can’t immediately see how this ties into the launch of self-funded feeds/marketplace. Also, any efforts to deploy would be led by the dAPI team. Unsure if I’ve misinterpreted this or overlooked key points, but want to make sure expectations are aligned here.

We now are in contact with their ecosystems, and developers are aware of API3 as an oracle project. When we do plan to deploy dAPIs in other places, we should have more awareness on these chains.

There is also an underlying level of knowledge about API3 within the blockchain ecosystem that is hard to measure, but being in more places cannot hurt it. I particularly look forward to seeing how the ecosystem proposal can help leverage these initial connections to improve developer awareness and usage across the over 20 chains on which we now have live products.

1 Like

At this point this is so far out i wouldn’t be promising or having talks with them about this at all. The overall goal is still to actually deliver these things on 13 chains first, which is a mammoth task in itself. I just wanna make sure that you know that we’re talking at minimum 1+ years here.

1 Like

Yes, I know, and that’s what’s been communicated (as in no timeline, and after everything else is done) - mostly this comes up when speaking to chains for QRNG. Overpromising would be harmful to our reputation