[Secondary Proposal 52] byog proposal, November 2022

byog proposal, November 2022

Period: N/A*

Amount: 200,000.00 USDC

Destination: 0x5846711B4B7485392C1f0feaeC203Aa889071717 (bbenligiray.eth)**

* See the “About byog” section below.

** The destination is a hardware wallet owned by Burak.

Proposal parameters

Creator: bbenligiray.eth

Target Contract Address: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 (USDC)

Target Contract Signature: transfer(address,uint256)

Parameters: [ “bbenligiray.eth”, “200000000000” ]

About byog

See the Medium post about byog. The aim of this proposal is to bootstrap byog as an independent organization (rather than a team that receives periodic grants), which is required for it to operate a credible first-party oracle. Therefore, despite working very closely with the dAPI team, it is designed to be a separate entity that lives in the API3 ecosystem, similar to ChainAPI. This implies that byog will pursue funding from other sources and opportunities to generate revenue, but again, similar to ChainAPI, the needs of API3 regarding its data feeds will take precedence.

byog launched 1560 testnet Beacons before this proposal was submitted, which included making the necessary improvements to the API3 codebase to enable this use-case and building an API that reliably provides a wide variety of crypto asset prices. This was done to prove byog’s capabilities regarding delivering on the responsibilities listed below.

Note that API3 provided testnet Beacons only on Polygon-Mumbai, which was far from ideal. Therefore, the testnet Beacons solve a significant problem of API3 and arguably deserve a retrospective grant even by themselves.


  • Serve as an independent data provider whose incentives are well-aligned with of API3’s

  • Contribute to the API3 codebase to improve the capabilities and UX for API providers building their own bring-your-own-gas Beacons

  • Develop and operate byog Beacons, which will act as the base-level service for dAPIs, as explained in the first dAPI team proposal

  • Integrate APIs, guide API providers through Airnode deployment and maintenance to power data feeds (note that this takes on the responsibilities of the now-defunct API integrations team)


Currently, byog burns 4,500 USDC/m for grants to individuals (Bedirhan and Mertcan, who were on the August–October 2022 core technical team proposal) and ~1,250 USDC/m for various expenses. The goal is to scale up the operation in a way that aims for a runway of 1 year.

Burak will control the budget and will not personally receive any grants from the funds granted for this proposal. If byog no longer fulfills the responsibilities above despite them being required, Burak will return the remainder of the funds to the secondary agent. Otherwise, the entire budget will be used to cover byog grants and expenses.


byog will mostly serve an operational role for API3. API integrations being implemented and maintained for data feeds, and the byog Beacons operating as usual will be the main deliverables of this team.


is it 4.5k/individual/m?
if so the numbers you mentioned add up to ~120k so i’m wondering why you’re asking for 200k - is the buffer 80k amt for “scaling up”? what does that entail?

1 Like

It’s $4,500/mo total for 2 full-time developers at the moment. Scaling up means hiring as many similarly cost-efficient developers as possible, which are difficult to find, so there’s no real way to plan this.


Hi everyone,

I have a few clarification q’s about the BYOG to dAPI onboarding:

From the BYOG blog post:

Moreover, after an evaluation period, these Beacons will be onboarded to the API3 Market as single-source dAPIs. The users will either use these as-is for free, or sponsor their upgrade to the level of decentralization they require, which will also grant service coverage.

(1) “use these as-is for free” this means a user can request API3 to add any BYOG Beacon on API3 market mainnet?

(2) If so, is this new beacon considered a BYOG Beacon or a BYOG dAPI (from monetizing data feeds post)?



This is more of a dAPIs team question but we’re in agreement anyway so I’ll answer

(1) All byog Beacons will be added to API3 Market just in case, without requiring a user to request them. This requires some changes to the Market design, which is what Phase 1 in [Secondary Proposal #45] dAPI Team Proposal #1 refers to. Not all of these Beacons will necessarily support aggregation upgrades (Phase 2) or coverage upgrades (Phase 4) on the Market because byog doesn’t consider if API3 will be able to find adequate number of alternative sources or would be willing to cover a kind of dAPI before deciding to set up the respective Beacon. (So for example, byog will set up a Beacon for a pair with low liquidity and that will be served as a 1 Beacon dAPI with no coverage, that appearing on the Market doesn’t mean you can buy coverage for it, which also makes aggregation obsolete. The main risk factor with such data feeds is that the underlying market is easily manipulable, and aggregation doesn’t solve that.)

(2) All dAPIs will start off as 1 byog Beacon dAPIs, and users will be able to pay to upgrade a dAPI to use as many sources as they want. There are two practical reasons for starting off with byog: (A) It allows us to maintain dAPIs with no users so that onboarding to a data feed that was never used before takes a matter of minutes (funding the respective sponsor wallet). This requires the API provider to be fine with running thousands of Beacons with no users without any compensation, and for that the incentives need to be perfectly aligned. (B) Single Beacon dAPIs are more difficult to pull off successfully compared to aggregated ones because they’re not as fault tolerant. This means we have very specific requirements from the API provider that will power them, which has proven to be a difficulty. byog’s API is built specifically to power these Beacons, and according to our monitoring it is more reliable than the previous methods of operating single-Beacon dAPIs that we have tried.