[Secondary Proposal] API3 DAO BD Team Proposal #9

Business Development Team Proposal, November 2022 – January 2023 (Cycle 9)

Team: Business Development Team

Operations cycle: #9

Period: 1 November 2022 – 31 January 2023 (3-months)

Amount: 7,232 USDC

200k API3 tokens revocably vested over 3-years for Kevin - this will be supplied from the multisig dedicated for API3 token incentives as detailed in the proposal here [Primary Proposal 2] API3 Hot Wallet if this proposal passes, not from the DAO treasury. This is intended to allow Kevin to adequately participate in governance.

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 data oracles and data feeds for Web3. This is accomplished through our building block infrastructure stack i.e. the Airnode and other data oracle innovations (dAPIs and Product ‘X’). Thus, achieving ubiquity in API3’s product suite remains a sole focus of BD.

Product ‘X’, we believe will be an end-game product that will change the face of DeFi and the larger Web3 ecosystem. In this proposal, product ‘X’ will be synonymous with this new innovation.

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

  • 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

  • Kevin will become the Go-To-Market lead for product ‘X’ and will contribute towards our go-to-market strategy along with the foundation for the upcoming sales campaign. For this role, Kevin will receive vested tokens as as an incentive, and to allow governance participation.
  • During this last cycle, core teams were rearranged and grant costs streamlined. The prior grant recipients have opted to remain involved with the DAO but will receive no grant until such a time that we can scale or market conditions improve:
    • Alex - is on a commission only structure
    • Mo - is on a commission only structure
    • Nathan - is a on commission only structure

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, which are key for the development of dAPIs and product ‘X’. In addition to these tasks and working alongside Dave and Kevin, he will assist in overall BD growing out our latent pipeline and interactions. Gio will update us on enterprise movements and large deal flows, as well as, any PoCs of Pilots that are complete.

Completed Deliverables (Cycle #8)

During cycle #8, the following progress has been made from the last Enterprise Team Quarterly Report.

Following-through from the previous quarterly update:

  • Update 1: A large market data provider (A) - status: in 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, but there may be a funding gap on the dApps side, which may affect their ability to deliver the end result which could act as a major blocker to delivery.
    • In the interim, we have another dApp we are speaking to whom may assist before this pilot period expires - 31st December 2022.
  • Update 2: A large financial data institution (B) – status: still engaging
    • We are meeting their team again in Cycle 9 to discuss a more serious engagement when it comes to their digital asset strategy.
  • Update 3: A large reinsurance institution (C)– status: still engaging
    • We will circle back one more time before stopping this engagement.
  • Update 4: A large consulting house (D) – status: at the commercial signing phase
    • We will circle back one more time before stopping this engagement.
  • Update 5: A medium-size crypto market data provider (E) – status: at the commercial signing
    • We will circle back one more time before stopping this engagement.
  • Update 6: A medium-size market data provider (F) – status: at the commercial signing phase
    • We will circle back one more time before stopping this engagement.
  • Update 7: A large-size market data provider (G) – status: interaction closed.
    • Nothing transpired from this interaction.
  • Update 9: A large-size crypto market data provider (H) – status: placed the interaction on hold. Will resume in the next cycle.
  • Update 10: A large enterprise blockchain provider (I) – status: at final stages
    • We are finalizing the vendor agreement.
  • Update 11: A nation-state federal department (J) – status:
    • We will circle back one more time before closing this engagement.

New engagements over the quarter:

  • Update 12: A large-size crypto market data provider (K) – status:
    • Met at Token2049 Singapore, need to follow-up with collateral.
  • Update 13: A large-size crypto market data provider (L) – status: met at Token2049, call to take place
  • Update 14: A medium-size market data provider (M) – status: moving forward (Crypto, Forex and Equities)
  • Update 15: A medium-size market data provider (N) – status: at the initial call stage (Crypto, Commodities, Forex and Equities)
  • Update 16: A large financial data institution (O) – status: early engagement.
    • We met a team member in Singapore for an in person demo.
    • Gio to send additional collateral and follow-up.

Furthermore, during this period, Gio met with some ecosystem partners in Singapore to ideate some PoCs.One of which is at the technical feasibility stage where we are assessing the source APIs and compatibility to the dApp use-case.The use case would look at a novel way to achieve a DID (digital identity for web3/DeFi.

The Quarterly Enterprise Reports will be discontinued, as marketing will announce any interactions or partnerships that can be disclosed.

Deliverables (Cycle #9)

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 between 7-10 sources for aggregation or switching. While this is being done, Gio will assist Kevin and Dave in accomplishing project ‘X’ and driving 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, self-integrate the provider (via ChainAPI) and then discuss and sign commercials. The commercial elements include a revenue sharing model.

Provider goals:

  • In Cycle 7, three providers were signed with datasets that include (Crypto, Forex, Indices,Commodities and Equities);
  • In Cycle 8, two additional partner providers were signed (i.e. one that only does forex). The latest provider is undergoing technical compatibility testing and data quality (Crypto, Forex, Equities)
  • In Cycle 9, the goal is to bring two to three providers to undergo technical compatibility testing and data quality, bringing this within the desired goal range.

2.BD – 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 product ’X’s narrative and awareness, working closely with the Ecosystem subteam.

Completed Deliverables (Cycle #8)

At the end of cycle #8, API3’s total TVS is still composed entirely of request-response protocol usage, awaiting production ready dAPIs. The timeline to dAPIs will give the BD team more time to prepare and build tooling necessary for effective outreach and onboarding once dAPIs are live, which will be the main focus for this cycle.

QRNG total usage over this cycle is hard to give figures for due to monitoring issues over the summer. These are now resolved, and across the various mainnets QRNG is live on there have been approximately 500 fulfilled requests over the last month. Initial conversations about deploying QRNG on other chains have also taken place.

Deliverables (Cycle #9)

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 9 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 believes 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. These extra chains will form a deliverable, and we expect a minimum of five extra chains to have QRNG deployed. These chains will then form a part of the wider API3 ecosystem in preparation for both product ‘x’ and the dAPIs being more widely available.

3. BD – Product ‘X’ and dAPIs

Kevin will work closely with the dApp and Enterprise teams but will primarily focus on the go-to-market/sales strategy for product ‘X’. This will be approached in three phases:

Phase 1

Phase 1 looks at the current proposal and actionables for Cycle #9.

Sales Planning:

While this proposal is being written, there are facets of the whitepaper and monetization policy that are being calcified. To run a successful sales campaign, initial planning on how we reach out to a project as a potential sponsor, as a ‘free service’, or as a longer-term revenue opportunity need to be considered. There is a potential for complex sponsor-user relationships to come into play and a thoughtful order of outreach will be required.

A strategy to expose product ‘X’ will be developed so that its value proposition stands out as an obvious ‘end-game’ innovation for DeFi and becomes an attractive enough option that all projects will want to use it. Planning will remain critical to ensure results are maximized for the DAO.

CRM:

Integrating customer-facing roles to the same CRM will greatly improve efficiencies moving forward. The sales-cycle for what we do is unlike any other kind of sales, and some obscure features matter a lot. Standardizing the CRM is paramount to handle the amount of onboarding/integrations we plan on doing as well as having oversight of both prospects and team metrics.

Sales Collateral:

We need a way to show estimates of value for what a dApp’s ‘future economics’ may look like by using our new product. Having some kind of numeric figure based on historical performance is a critical sales tool and will help us gain users. While the actual accounting for each dApp will be separately determined after launch, being able to give dApps a rough estimate during the sales process will allow us to gain immediate traction. Before we launch we should be able to reach out to every dApp in the ecosystem with a proposal that clearly shows the benefits of our new product.

Commission Survey/Structure:

A commission structure that allows for Salespeople to find success is an important piece of any well-functioning organization and will drive value towards the DAO.

This task boils down to creating an ‘On-Target Earnings’ metric where various sales KPIs and expected closings are defined to ensure accountability from all parties involved. Doing so will allow compensation to reflect the guidelines already outlined by API3, and for us to govern our outreach pipeline for performance and self-direction. A survey of comparable organization’s structures will be completed to give us a baseline to work from.

Soft Outreach:

Attending conferences/speaking engagements in a limited capacity to generate and continue initial interest in our product.

Phase 2

Phase 2 provides the guide for the next proposal. Thus, planning ahead for Cycle #10 will emanate from this phase.

Integration Clarity: Working with the appropriate stakeholders from other departments, we need to standardize our integration pipeline. Before we launch, I will work across the various verticals to cement ownership of the various integration points so we can be as efficient as possible as we move forward. This is relevant to Lead Ownership, Onboarding, and eventually Account Management.

Internal educational materials to help onboard new (or existing) members: Even if you’re crypto savvy, selling this new product requires a high level of expertise. I will help make onboarding/training materials to help bring people up to speed on how exactly we are going to sell the product.

dApp Qualification/Initial Outreach Campaign: Although the release timeline has not been cemented, it is around this time that we can look to restart targeted outreach to the community. We want to hit the ground running at launch and will need to secure a critical mass of MOUs and commitments well before we go live. This will be done through outreach and ecosystem workshops to drive interest.

Phase 3:

Phase 3 looks at Cycle #11 and implementing actual ROI as API3 readies for product “X” and dAPI launch. It will focus on the following areas:

Full Sales Campaign: Once our project is fully ready for market, we will run a full sales campaign of outreach and closings. This is our most important task and will form the bulk of our duties going forward.

Sales Skill Workshops: To ensure we maximize our potential, I will run periodic sales workshops where we can discuss the product, how to run presentations, how to handle objections, how to best do outreach, and how to best maintain ourselves as product experts. Sales skills need to be continually sharpened and having a space to do so will be beneficial.

Grow Team as Needed: At this point (maybe before), it will be apparent whether we need to onboard more Business Developers. When required I will help recruit, onboard, and train new hires.

Account Management/Upselling: Once we have projects onboarded, relationships will need to be maintained, and we will have opportunities to upsell clients on our suite of products. This will be a continuing task with recurring client reviews.

Business Development Budget

Amount (USDC)
Grants 19,125
New BD Grants (Paused) 0
^Expenses & Success Commissions 21,000
Grant Sub Total 40,125
Total Credit Roll over from last cycle -32,893
Grant Total (Less Roll-over) 7,232

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 Product “X” and dAPIs g2m #Token incentive
  • 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

200k API3 tokens vested over 3-years for Kevin - this will be supplied from the multisig dedicated for API3 token incentives as detailed in the proposal here [Primary Proposal 2] API3 Hot Wallet if this proposal passes, not from the DAO treasury

Success commissions will be paid to eligible BDs for successful and working QRNG integrations.This will come from the expense and success commission allocation. We project 5-10 integrations over the cycle.

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 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.

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

A few questions/concerns that come to mind:

(1) Paying 200k tokens vested over 3 years seems to be on the far high end of token allocations for BD. How was this 200k number derived? Where does this fall in terms of average BD token grants?

Does it not make better sense to raise the token allocation based on incremental milestones? For example: Start 50k, if X number of integrations occur, 75k, etc., etc.

This is an excellent opportunity to outline how the hot wallet determines token allocations for new contributors. If it’s simply by a proposal passing, or specific guidelines should be followed to qualify for a request of X amount of tokens. Establishing clarity for TA is probably in the DAOs best interest.

(2) Compensation in tokens has legal implications for the API3 Foundation, especially for US contributors. Will a third party handle API3 token payouts and federal and state taxes withholding? I know a third party already does USDC-USD taxes for US-based contributors, but taxes on API3 tokens to USD seem a bit more complicated. Is such third party aware and agreed to work on such token to usd tax implications? Given the US regulatory climate, we should tread carefully in such scenarios.

Perhaps @Erich can chime in here concerning Tokens as compensation and any other legal implications to consider, if any?

(p.s. this post is not questioning Kevin’s ability, but rather the token allocation process as a whole)

Cheers,
R

1 Like

In response to your questions:

(1) Kevin would not be taking any USDC grant, so this represents the entirety of his incentive. He will also be a co-lead, hence the number. At current token value this is equivalent to other proposal lead grants. There is also general consensus within the hot wallet signers that this is an appropriate governance token allocation for the value he brings.

The vest is revocable, so if value for money was not being delivered, it could be revoked. I have every faith in Kevin that we will not need to do this, but theoretically it would be possible.

Previous token allocations have not always been included on proposals like this, often generally taking place solely as conversations with the hot wallet signers, but we felt it important in this case for transparency around BD compensation generally.

(2) How do all the other US based contributors with existing token grants handle this? I am confident there is a compliant way this can be dealt with, without needing to pay the 15% fees that the USDC-USD third party charges

For (2), taxes are always the sole responsibility of the recipient/grantee (as nobody is an employee of the Foundation, only contractors or unilateral grantees) - whether that’s accomplished directly individually or through a third party entity that contracts with or employs the grantee differs by situation according to the details (nature/length/recurrence of contributions, domicile, etc.). There are several existing third party entities that provide this service for individual contributors; I am not sure of Kevin’s status (individual or though an entity) or preference.

It’s true that it’s typically best to avoid using API3 tokens as a sole substitute for compensation, especially if a recipient isn’t receiving meaningful compensation from elsewhere. Mitigants for this are if the recipient is justifiably expected to or intends to be a substantial participant in governance using those tokens (seems likely here), if there are other avenues for compensation through these efforts (always a possibility to drive value to other pursuits using API3’s open source tech and services), etc. I defer to Kevin as to details like these.

1 Like

Thanks, Erich. Thank you for clarifying, @Dave. I am sure Kevin will bring lots of value to the team and API3’s endeavors. However, it’s in the best interest of the DAO to create some objective processes and procedures that go into qualifying for TA, quantity, and revocation of TA that can be used for future contributors.

For example, there was a vigorous discussion not too long ago regarding the grounds that a contributor’s TA is revocable. This current TA proposal presents an opportunity to outline on what grounds a TA is granted and revoked.

Therefore, as a DAO, we should create clear guidelines to uphold individuals in TA, quantities, and unfortunate or unforeseen circumstances that constitute a revocation.

The hot wallet proposal does have guidelines (specifically its one paragraph description) and I find it adequate because while considering a token allocation, the question of “Does the hot wallet proposal say that this is a valid allocation?” tends have a clear Yes/No answer. Also, this was a primary DAO proposal, so it’s one of the two proposals that were indisputably agreed on “as a DAO”.

200k API3 is a lot of tokens and referring to the current price is imo misleading. That being said, I’m in favor of a lean and effective BD team, and would love to have someone who would deserve that allocation in it. Kevin has been contributing to the BD team for a while and based on experience they claim that he is worthy. This and the following proposals that include him passing (or not) is the most unambiguous signal for what the DAO thinks about that.

2 Likes

What is product ‘X’?
Surely at this stage in API3 forums there are no more ‘random speculators’ left, and would be great to get some more inclusive updates as to what is happening or the updated roadmap/product prospect summary

This is supposed to be a pretty big update that intends to change the overall direction of API3 and even the wider crypto space, which is why they want to keep it under wraps
Should be made known shortly but shouldn’t be too much of a surprise to a close observer

1 Like

Product X

2 Likes

Thanks Tom, you beat me to this https://twitter.com/API3DAO/status/1587433208890564609. OEV data feeds are the product X referred to in this proposal

2 Likes

pls move to official governance and announce as such
i think i can do it for you

1 Like

fyi you’re linking to an old proposal on the official on-chain proposal.

1 Like

Sorry everyone, as @UgurMersin pointed out above (and @kcorstor in DMs), somehow my IPFS link was incorrect. I’ll post up a new proposal, in the meantime this should not be voted for

I’m unsure if it warrants a new proposal as the parameters are correct with the exception of the IPFS link. Just wanted to point that out :<

I think for transparency and keeping a full record (without having to cross reference the forum) it might be best. The correct document is just the text from the forum post above, with the IPFS link https://gateway.pinata.cloud/ipfs/QmNqWaYbX9Gw6He1QYZeGMi32dgd7NW9zy9vQ2PuHivMHN

1 Like

A new proposal has been posted with the correct IPFS link - https://api3.eth.link/#/governance/secondary-44.

2 Likes