Business Development Team Proposal, August-October 2022 (Cycle 8)

API3 DAO BD Team Proposal

Business Development Team Proposal, August-October 2022 (Cycle 8)

Team: Unified Business Development Team -

(dApps & Platforms BD, Enterprise BD, dAPI/Beacon BD)

Operations cycle: #8

Period: 1 August 2022 – 31 October 2022 (3-months)

Amount: 26,738.23 USDC

Destination: Gnosis Safe (Multi-sig wallet)

address 0xE2279B907f027CC89fE744B2b5cf46F978e502d3

signers:

Dave - dav3.eth

Gio - 0x3afB3530Da3CBa4d8B278Af63872FAA80F1fC87D

Alex - 0xDF3801FBf19C1Bd0af6D24C483A3781129Eee65d

2/3 Multisig

Scope

The Unified Business Development team drives holistic organizational-wide value within the DAO. Sub-teams consist of Enterprise Development, dApps and Platforms and dAPI/ Beacon focused Business Development teams.

Each sub-team is self-driven, targeting various elements of business development as it translates into the achievement of quick-wins. This is achieved through smaller actions and accomplishments on the micro level. This gives the team the ability to zoom out/in while aligning on the greater unit’s collective goals on a macro level. The team cross-pollinates ideas, synchronizing areas of overlap which leads to greater coordination and utilization of resources.

API3’s vision is to be the first choice, in open-source software infrastructure as it pertains to data oracles and data feeds for Web3. Thus, achieving ubiquity in the API3’s product-use, remains key in achieving traditional industry standardizations similar to that of QWERTY keyboards, USB, Bluetooth etc.

The BD team remains lean and is focusing on scaling-up and expanding the adoption of beacons and dAPIs up-take. This translates into direct DAO value, pushing ROI and revenues from beacon and dAPI subscriptions which is explained more in Section 3. BD – dAPI/Beacon Focus.

For the purpose of this proposal, the Business Development Teams responsibilities encompasses customer-specific tasks and overarching responsibilities that relate to:

Sales process

  • Outreach
  • Continuous improvement of outreach processes
  • CRM structure

Recruitment & HR (In-line with product growth)

  • Onboarding
  • Training
  • Practice
  • Ongoing support

Reporting

  • Accounting processes

Coordinate with the marketing and ecosystem sub team’s

  • Projects in the ecosystem
  • General networking
  • 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

Internal workshops and meetings

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

Team Movements

Over the course of the cycle, there has been one team member addition and no further internal movements.

  • Kevin, is focusing on growing beacon feed uptake. He further specializes in data analytics and assists other teams in number crunching and statistical analysis where needed.

  • Joeri, is still in an advisory capacity from his previous part-time designation in providing ad hoc introductions, strategic guidance and networks where needed. His grant compensation has been removed.

1.BD- Enterprise Focus:

The Enterprise team has the following responsibilities in addition to general business development activities. The business development scope of the project will expand over time, and this list represents the current state.

I* n conjunction with the dApps team lead, the Enterprise team lead sets and implements strategic actions within the BD team

  • Meet the general business development framework, outlined above

  • Oversee and support the BD team sales funnel

Host Enterprise workshops:

  • Enterprise consortia technical integration workshop to explore Airnode integration feasibility across consortia members
  • Product demo of Airnode-enabled product developed by Technical Integration Engineer
  • Enterprise use case workshop with Enterprise prospects

Proof of Concept development with Enterprise customer(s)

  • Enterprise Airnode integrations
  • Custom solution development
  • Link enterprise customers with implementation partners for any smart contract or dApp development

Completed Deliverables (Cycle #7)

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

The Enterprise team in close coordination with the technical team hosted two new workshops with:

  1. A large consulting house – status: at the commercial signing

  2. A large financial data institution – status: still engaging

Our goal with PoCs/Pilots is to demo live use-cases of the Airnode and make large TradFi (traditional finance) players feel comfortable with the technology, while reducing any risk vectors (regulatory, tech or DeFi-wise).

Following-through from the previous quarterly update:

  • Update 1: A large weather data provider – status: signed and closed
  • Update 2 : A medium-size market data provider (A) – status: signed and closed
  • Update 3: A large market data provider (B) - status: in pilot testing phase
  • Update 4 : A large financial data institution – status: still engaging
  • Update 5 : A large reinsurance institution – status: still engaging
  • Update 6 : A nation-state federal department – status: still engaging

New engagements over the quarter:

  • Update 7: A medium-size market data provider (C) – status: signed and closed
  • Update 8: A medium-size market data provider (D) – status: signed and closed
  • Update 9: A large consulting house – status: at the commercial signing phase
  • Update 10: A medium-size crypto market data provider (E) – status: at the commercial signing
  • Update 11: A medium-size market data provider (F) – status: at the commercial signing phase
  • Update 12: A large-size market data provider (G) – status: still engaging
  • Update 13: A large-size crypto market data provider (H) – status: still engaging
  • Update 14: A large-size crypto market data provider (I) – status: still engaging
  • Update 15: A large-size market data provider (J) – status: still engaging
  • Update 16: A large-size market data provider (K) – status: still engaging
  • Update 17: A large enterprise blockchain provider (L) – status: still engaging

During the cycle, the Enterprise team attended the following events over the quarter: the Ethereum Enterprise Alliance Showcase (virtual), APIdays India (virtual), APIdays Singapore (virtual), APIX Brazil (virtual) and Consensus Austin (face-to-face). The outcomes of which have led to tier 1 leads which are currently being engaged. While at Consensus we met with some of our dApp partners and networked with key projects.

The BD team attended the EthCC 5 conference in Paris (API3 was a sponsor), in order to launch the data feed products and prospects for new dApp customers. Our data feeds are available on Avalanche, Polygon, Rootstock and Binance Smart Chain. You can learn more here. We want to thank the Marketing team for making this a success.

Finally, the team continuously has ongoing efforts on researching and outreaching other relevant industry associations, enterprises and consortia.

You can view the current quarterly progress report here , for further insights.

We will also endeavor to update the community, as soon as large deals are signed and legally possible – due to some of these large interactions are of strategic importance or can have effects on brand reputation aspects.

Previous quarterly reports:

API3 Enterprise Development Report, August/September 2021

API3 Enterprise Development Report, September/October 2021

API3 Enterprise Development Report, November-December 2021, January 2022

API3 Enterprise Development Report, February, March, April 2022

Deliverables (Cycle #8)

As for the last two cycles, we are following-through and moving forward with the interactions 3-6 and 9-17 outlined above (Cycle #7). For business development cycle #8, the enterprise-facing business development team’s main focus is to grow the number of high-quality crypto/market data providers to connect additional data feeds and dAPIs.

This focus will create robustness and choice within the data feed product while offering all crypto and TradFi based financial instrument data. Thus, the priority will be to outreach, secure and continuously engage with our partners. The Enterprise team will further support the Technical and Ecosystem teams, from the business side to ensure smooth integration and continuous touchpoints with our partners. A secondary priority would be focusing on PoC/Pilots with large brands to drive Airnode and data feed ubiquity within the mainstream TradFi segment.

The enterprise approach and strategy has been working well and we will continue this at a faster pace for cycle #8. This is through email interactions, virtual and face-to-face conferences and venture capital networks. In this way, we will continue to showcase PoCs and live Airnode use to large partners.

The Enterprise team in coordination with the Marketing and Ecosystem teams will also endeavor to create PoC videos and materials that any dApp or Enterprise can pick up and ideate with. This will showcase the Airnode’s potential and its application to beacons/dAPIs in action. The Ecosystem team will focus on driving the developer community while in parallel getting input from enterprises, dApps and providers.

For the next cycle the Enterprise team will be attending (virtual and/or face-to-face) events and finding opportunities to partake in various Industry-focused conferences as delegates or as speakers: Ethereum Enterprise Alliance (EEA), Token 2049 Singapore, ETH Lisbon and Solana Breakpoint Lisbon are tentatively on our schedules.

2.BD – dApps and Platforms:

In addition to the above business development responsibilities, the Platform/dApps BD team will focus on building-out the dApp and Platforms ecosystem. The overarching aim is to improve the options for developers looking to use API3 data by deploying on as many platforms as possible, and reach out to the projects being developed on these to find consumers for our beacon, dAPIs and Airnode-enabled APIs.

Outreach (Platforms & dApps)

  • Communicate with projects and platforms identified through R&D
  • Identify areas for collaboration
  • Propose a deliverable and mutually beneficial solution
  • Establish integration potential and discuss marketing to developers

Communicate with development team and integration team for integrations

  • Smart contract platforms
  • dApps

Communicate with the Marketing sub team to raise awareness among the general community

  • Co-author blog posts
  • Ensure technical content of posts correct
  • Schedule announcements, verify content and timing with partners
  • Discuss and align publicity requirements with prospective partners and marketing

Communicate with the ecosystem sub team

  • Help raise awareness of API3 within each chain’s developer communities, taking part in events where it would be beneficial.

Completed Deliverables (Cycle #7)

At the end of cycle #7, API3’s total TVS is still composed entirely of request-response protocol usage. dAPI usage is only just approaching production readiness, so although we are unable to include any from this cycle, we expect to be able to include TVS from this for next cycle. The BD team plans to collaborate with the marketing team to ensure the TVS will be accurately tracked by DeFi dashboards like DeFiLlama.

API3 also launched QRNG during the last cycle. As QRNG is a public good, and projects are not in any way obliged to partner with us to utilize it, tracking number of requests is a good way to monitor adoption. At the time of writing this proposal, there were over 3.8k requests for random numbers across all supported chains including testnets, of which approximately 1k were one of the supported non-testnet chains. The majority of these requests were made on Fantom, Moonbeam, Polygon and Gnosis Chain. Projects using QRNG include Exiled Racers, Quantomons, Pipcards and Dystoworld.

Deliverables (Cycle #8)

As dAPIs enter production, we expect TVS will also provide an objective indication of success. The BD team will continue liaising with the marketing team to ensure this is available as a metric on existing DeFi dashboards once the first dAPI users are on boarded and live in production.

3. BD – dAPI/Beacon Focus:

The API team has evolved towards a fluid team that expands and contracts based on demand. The team leads of dApps and Platforms and Enterprise are managing and guiding this team’s success.

This is the general team that new joiners start in and if they prove their abilities can move into other critical or needed roles within the wider DAO. Thus, this unit will have a high turn-over rate with those proving their BD skill and grit.

In addition to the above general Business Development responsibilities, the BD-dAPI/Beacon team responsibilities relate to growing the number of new and active subscriptions for dAPI and beacons.

Customer Relationship Management and growth

  • Lead generation
  • Lead engagement
  • Account management

Qualifying dAPI opportunities

  • Researching and lead generation
  • Following up on open or not outreached interactions within the database
  • Aiding other business development teams through the sales funnel

Completed Deliverables (Cycle #7)

During the cycle #7 Cycle, the API team pivoted to focusing on dAPI/ beacon outreach providing assistance across BD verticals. In addition to this focus, Alex has been focusing on building out and strengthening our Quantum Random Number Generator (QRNG) product. We announced a partnership with the Australian National University (ANU) Physics department bringing its QRNG generation to Web3 and DeFi. API3 sees the QRNG product as a public utility that grows randomness inputs for dApps and smart contracts with applications for online gaming, NFT creation and security. The API3 QRNG is available now on: Arbitrum, Avalanche, BNB Chain, Ethereum, Fantom, Gnosis Chain, Metis, Milkomeda-Cardano, Moonbeam, Moonriver, Optimism, Polygon, and RSK.

In addition to this exciting partnership announcement, we have continued to deepen relationships with the world’s top quantum number providers for our QRNG product. The goal of which is to add one or two additional QRNG providers to make the number generation tool more robust, achieving ‘true’ randomness. Other notable interactions over the quarter includes a fintech marketplace with an array of financially focused APIs which is still ongoing.

The next cycle’s focus will be on driving ROI through dAPI/beacon subscription uptake.

Deliverables (Cycle #8)

The next cycle’s focus will be on targeting dAPIs/beacon uptake in active subscription sign-ups and the QRNG adoption within dApps and use-cases.

Due to the current market conditions, we have suspended active hiring on the team. We have refocused our attention to drive beacon subscriptions across our sub team. There are still success commissions for successful deal closures which aligns directly to revenues in, to compensation payments made out to BDs.

Once we reinstate the hiring process, new BDs will be given a small grant for the first three months, thereafter, the grant base will fall-away and rolling subscription commissions will be the primary source of BD commissions.

The initial grant given is to give the BD the opportunity to build up their rolling subscription book to a sustainable point and show their BD acumen and skill. This incentivizes high-performance without a continuous grant outflow. It further aligns as when API3 receives subscription revenues; commissions are paid. Thus, a core focus is achieving a balanced cash-flow and sustainable approach to BD.

Business Development Budget

Amount (USDC)
Grants 40,125
New BD Grants (Paused) 0
Expenses & Success Commissions 34,100
Grant Sub Total 74,225
Total Credit Roll over from last cycle (UNI-BD) -47,486
Grant Total (Less Roll-over) 26,738

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 4,375.00
*Alex Business Developer Enterprise, dApps & Platforms, APIs 3,000.00
Mo Business Developer dApps & Platforms 2,000.00
Kevin Business Developer & Analyst dApps & Platforms, APIs 2,000.00

*The destination will be a multi-signature wallet address managed by Dave, Gio & Alex . Requested compensation levels are as per the API3 DAO Compensation Guidelines

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 an allocation for BDs in order to ramp-up active subscriptions for beacons/dAPIs.

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:

  • 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 see a larger-than-estimated number of expenses tied to performance or of business development 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

The proposal is live and up for vote:
https://api3.eth.link/#/governance/secondary-34

University Vote
  • Approve
  • Disapprove
  • Actively Abstain

0 voters

Last minute comment but anyway

Is there a breakdown of what the expenses and success commissions are like in detail? If not at this point, dw
You mentioned bringing in tier 1 partnerships from conferences - wdym? I assume that’s referring to the currently unnamed larger entities
Implementation partners - have they been put to use with enterprise partners yet? Are these in the PoC stage? Does the integrations team fit in here?
For updates 1 and 2 from the previous cycle, they’ve been listed as signed and closed, and have been made public already right?
What is the status exactly with top QRNG providers? Assuming the business agreements are set in stone, would a monetized dQRNG just need an aggregation contract from the tech team to be plugged in, or does it require more bespoke development?

Commending the very low requested amount btw - only 27k

1 Like

Sorry for the last minute comments from me as well. First, the math is not adding up for me. In Cycle 7 the grant request was for $50,362.00 but according to this proposal you have a credit of $47,486 rolling over? That’s a difference of only $2,876, which wouldn’t cover more than on grant salary on the team more than a month. You do note UNI-BD in parentheses, is that the University Marketing team’s grant money that got passed over to you in some way? The comment with their vote is confusing me as to what accounts for that credit amount that’s rolling over, but obviously this is still a good thing since the grant request is substantially lower this cycle.

Lastly I’d like to suggest that you remove the accounting reporting and CRM structure items in your list of responsibilities from the Business Development proposals moving forward. These items are within the scope of the Operations team, and they have not received much if any collaboration from your teams.

1 Like

Hi Midhav, thank you for your proposal questions, happy to clarify.

Yes, we have a success commission table that breaks down the commissions per deal. At this stage we have kept the commission table closed to internal BDs and API3 team members only. I will check with Dave, as we could make it public (if that’s what you asking?)

A Tier 1 partnership is a household name or globally recognizable brand – think of the NASDAQ or Tesla for example (Btw, I’m not implying that we are/are not working with any of these examples). We keep enterprise engagements confidential for strategic reasons until announced by the Marketing team. For example, “a well-known Tier 1 Weather Provider”, was AccuWeather.

We are working with one unnamed implementation partner but this is at early phases to explore an opportunity/PoC with a LATAM stock exchange. The other implementation partners have not been used. The ecosystem team will further these relationships.

The integrations team works closely with the Enterprise team – Cam and his team have been amazing at assisting with PoC demos and content.

For the signed and closed – they are still to be announced for the price feeds product (other data categories/sets incoming from these signed agreements).

Alex is heading up the QRNG engagements but from my understanding, it would be to get one or two other top tier QRNG providers (which he is engaging) to create the dQRNG down the line.

1 Like

No worries Mason, any feedback is constructive. Happy to elaborate further.

During Cycle 6 and 7 there were a couple of changes that resulted in a surplus or roll-over from the last two quarters. The team reduced their grants and expenses proactively to extend runway and to be more efficient citing the bear market - exercising prudence. The LATAM team spun out into its own sub-team.

In Cycle 6 and 7 our budget incorporated funding to scale the BD team to drive data/price feed adoption and a budget for sales commissions. Mid cycle, we refocused our attention while putting a freeze on hiring. Only Kevin was added with set grant. In addition, since the price feeds are a new product, the sales cycle is a bit longer than the previous API signing days, so no success commissions have been paid as of yet. This was the surplus we currently have and the reason for us requesting only what we need in order to not strain the treasury.

The UNI-BD was the previous cycles naming convention “Unified Business Development", which was a result of merging all BD verticals in Cycle 5”. So, this is completely separate from the University. Thank you for catching this, I will make sure to be more explicit in avoiding conflation and revert back to just Business Development Team.

Sure, I can remove the accounting reporting and CRM structure items. The reason for it being there initially was to provide relevant accounting records and input into the CRM functioning, as a responsibility of the team leaders. I tend to disagree; we have been cooperative when it comes to providing accounting records and input into the current CRM functioning. Going forward it will be removed noting your comment and points.

thx for the replies

That wasn’t what I was asking for - was mainly just asking what this amount comprised of, since part of it is not just the success commissions but also some unnamed expenses from how I read it
I do think making it public would be useful though if possible, as I think it could incentivize outsiders to also join in on the action
And I guess it’d break down exactly what the commissions success amount consists of, as I assume that’d be an upper bound on exactly how much could be paid to biz devs if they hit the top tiers of premiums

Interesting, I was wondering if one of these was referring to an already published partnership like Accuweather

This has been going on for a while and from my understanding requires an additional pending proposal - I hope it gets sorted out soon @Ditto (Alex)
I was also asking about the technical aspect of it in case you/someone else in the team is aware of that

@Midhav It’s been progressing smoothly. Proposal should come shortly.

Can you please provide some examples of this?

A major reason that the CRM’s potential is not fully realized is that the entire originations side (new business secured from BD) is rarely implemented within the CRM or if so it is largely inconsistent. This inconsistency has actually created a lack of cohesion in cross vertical alignment and that won’t change without consistent adoption. Integrations and Marketing use this tool to coordinate between themselves, but BD continues not to incorporate much of the available CRM functions or even to simply add new business regularly, which would create a much more robust ecosystem where all verticals have been enabled to align and to rely on the accuracy of the system as a whole. This is a bigger concern as we begin to see increasing demand and complexity in coordinating between teams and with various end users and stakeholders. There is a palatable risk that a lack of CRM adoption from the originations side creates undue burden and complexity in the near future, and we should have a desire to avoid that given the aforementioned tradeoffs or perceived inconveniences associated with complete adoption of our CRM tool.

Today you asked for your team to fill out a spreadsheet where the CRM would make more sense, and you asked the Operations team for a data export of the dApp board that exists within the CRM. This seems to be a refusal to align to processes we are building for the betterment of the foundation as a whole as well as an accidental admission that there is merit in having a single data source to call on, which is why we’ve tirelessly designed and implemented a CRM in the first place.

When you post to the community that one of your functions is something you actively go against outside of your proposal I feel like it’s worth mentioning, especially since this has been a key issue that has stifled cross vertical visibility as well as overall cohesion across the DAO.

BD proposal passed.