Watchlists
Screener
Monitoring
Projects
Analytics
Research
News
More
Project
© Blockworks 2026
Product
ResearchNewsIntelScreenerRankingsWatchlistsCharts
Company
NewsletterPodcastsEventsBrand Assets
Resources
Terms of ServicePrivacy PolicyPrivacy CenterDocumentationPricing
Terms of ServicePrivacy PolicyPrivacy CenterDocumentationPricing
NewsletterPodcastsEventsBrand Assets
Project
OverviewChartsMonitoringToken DisclosuresResearchNewsMarketsToken UnlocksAbout
Fundraising
API3
Curious what full access looks like?
Access premium insights on ETH and BTC pages for free.
BTCETH

API3

Blockchain Infrastructure · Oracles
OverviewChartsMonitoringResearchNewsMarketsToken UnlocksAboutAPI3
OverviewChartsMonitoringResearchNewsMarketsToken UnlocksAboutAPI3

Token Transparency Filing

B1 v1.1 · Filed 23 Jun 2026Partial - 4 gaps

Project & Team

01

Description of Project

Provide a concise narrative that clearly states each of (a)–(e) below.

  • (a) Problem the project solves — The problem the project is solving.
  • (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
  • (c) High-level project overview — How the project works at a high level.
  • (d) Primary token functions — The primary functions of the token (e.g. gov participation).
  • (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.

(a) Problem the project solves

API3 states that decentralized applications increasingly need to receive data or trigger events using traditional Web APIs, while generic oracle solutions do not appropriately solve that API connectivity problem. API3’s stated solution is a network of blockchain-native decentralizedAPIs, or dAPIs, built from first-party oracle feeds operated by API providers. Decentralized APIsfor Web 3.0Oracles that pay you

(b) Operational priorities

Ongoing operations rely on maintaining and expanding dAPI services, capturing Oracle Extractable Value for partner dApps, administering staking incentives and collateralization through DAO governance, and funding contributors through DAO-approved grants for one-time projects and time-defined operations. Oracles that pay you Governance DAO Contributors API3 Public Token Distribution Event

(c) High-level project overview

At a high level, API3 describes its product as data feeds served across major EVM networks, with dAPIs composed of first-party oracle feeds from API providers and secured through on-chain aggregation. API3 also states that OEV generated from data-feed usage can be captured and paid back to partner dApps as OEV Rewards. Oracles that pay you Decentralized APIs for Web 3.0 Security considerations

(d) Primary token functions

The API3 token is described as the core token for governance, staking, rewards, and service-coverage collateral. Governance participation requires staking API3 in the DAO staking pool, stakers receive API3-denominated rewards, and staked API3 is described as collateral supporting on-chain service coverage. Governance Pool (Api3Pool.sol) Decentralized APIs for Web 3.0

(e) Control surface reliance

The current public control surface relies on DAO governance and a staking-linked control model rather than managerless operation. Governance participation requires staking API3, proposal creation requires at least 0.1% of the staking pool and no proposal in the prior 7 days, primary proposals require an absolute majority, secondary proposals require 15% support plus a relative majority, and both proposal types execute immediately once 50% of all voting power has voted For. Governance Working with Proposals

02

Known Project Team

For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.

Full Name

Entity

Official Title

Prior Experience

Burak Benligiray Source

Foundation

Core Technical Team Lead.

No public data found in cited sources.

Heikki Vänttinen Source

Foundation

Co-Founder

Early Chainlink node operator.

Blockworks note: The API3 team declined to provide known project team member information due to
confidentiality obligations.
No primary DevCo exists for API3.
The API3 team declined to provide known DAO team member information due to confidentiality
obligations.

03

DAO Structure

Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).

  • (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
  • (b) Contract/admin powers — List onchain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
  • (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
  • (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
  • (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., onchain vote threshold, board resolution of a legal wrapper).

(a) IP ownership & control

All IP is held by the API3 Foundation. The IP consists of trademarked logos and terms, copyrighted writings and software. Most of API3's software is open-source and available on GitHub. API3 DAO Documentation

(b) Contract/admin powers

The public record shows that the DAO votes on staking incentives, collateralization, and grant proposals that directly transfer DAO treasury assets to contributors. Staking is required for governance participation, proposal creation requires at least 0.1% of the staking pool and no proposal in the prior 7 days, primary proposals require an absolute majority, secondary proposals require 15% support and a relative majority, and both proposal types execute immediately once 50% of all voting power has voted For. Public security materials also state that Api3ReaderProxyV1 is UUPS-upgradeable, that a 4-of-8 multisig owned by API3 technical team members can upgrade it, and that a separate 4-of-4 technical-team multisig approves the Merkle-root configuration for data feeds. Tokenholders have the permissionless ability to make and vote on proposals which, if passed, permissionlessly transfer tokens from the primary or secondary treasury smart contracts and can update certain parameters of those treasury contracts. Proposal creation is subject to a threshold amount of staked tokens. Governance Working with Proposals Security considerations API3 DAO Documentation

(c) Locked-token rights (conditional)

API3 holders can stake tokens in the pool to acquire DAO voting power, receive API3-denominated staking rewards, and optionally delegate voting power to another user. The staking pool contract supports deposit, stake, scheduled unstake, unstake, and reward-mint functions, while reward emissions are adjusted through governable staking parameters such as stake target, APR update step, and minimum and maximum APR values. Pool (Api3Pool.sol) Reward calculation and distribution Working with Proposals

(d) Value accrual & holder rights

Staking API3 tokens in the DAO pool is the primary mechanism by which tokenholders accrue economic benefits. Stakers receive API3-denominated reward emissions minted directly into the staking pool, with APR adjusted algorithmically based on whether the staked share of total supply is above or below a 40% target. No fixed yield schedule exists. The cited public sources do not identify a formal mechanism by which protocol fee revenue or OEV capture is distributed to tokenholders; API3 states that 80% of captured OEV is paid back to partner dApps rather than to stakers. Treasury assets are controlled by DAO governance, with token transfers executed permissionlessly upon passage of a qualifying proposal. Governance

(e) Dissolution authority

The DAO smart contracts are noncustodial and do not include a kill switch or programmatic dissolution mechanism.

04

Primary Foundation

For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

The cited public materials identify the Foundation as API3 Foundation, a Cayman Islands foundation company limited by guarantee, and one launch-era token-distribution source describes the legal entity governed by the API3 DAO as API3 Foundation Limited Company, a Cayman Islands foundation. Api3 Terms & Conditions API3 Public Token Distribution Event

(b) IP ownership & control

The API3 Foundation holds the project's IP, which consists of trademarked logos and terms, copyrighted writings and software. Most of API3's software and licenses are publicly available on GitHub, linked through project documentation.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

The Foundation has no unique powers over the DAO or treasury smart contracts. Those are strictly governed by stakers of API3 tokens acting through onchain governance proposals. Public terms state that certain aspects of API3 governance may be substantially affected by or delegated to immutable onchain DAO smart contracts and protocols. Api3 Terms & Conditions

(d) Powers over DevCo

No primary DevCo exists for API3.

(e) Contract/admin powers

DAO smart contract admin powers are strictly governed by stakers of API3 tokens acting through onchain governance proposals.

(f) Current economic arrangements and distribution policies

Current DAO economic arrangements and distribution policies are strictly governed by stakers of API3 tokens acting through onchain governance proposals.

05

Primary Dev Co

For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

No primary DevCo exists for API3. Development and operational work is performed by numerous contractor entities and individuals rather than a single primary development company involved in token issuance.

(b) IP ownership & control

No primary DevCo exists for API3.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

No primary DevCo exists for API3.

(d) Powers over Foundation

No primary DevCo exists for API3.

(e) Contract/admin powers

No primary DevCo exists for API3.

(f) Current economic arrangements and distribution policies

No primary DevCo exists for API3.

Token Supply & Allocations

06

Initial Allocation

Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.

  • (a) Launch supply totals — The total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch.
  • (b) Recipient categories & use of funds — The recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket.
  • (c) Initial price per token (if applicable) — The initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
  • (d) Ticker / market symbol — The ticker/market symbol.
  • (e) Total supply & supply regime — The total supply and whether the supply is fixed (if not explain inflation rate or deflation rate).
  • (f) Initial vesting / release schedules — The initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).

(a) Launch supply totals

The cited launch-era token materials state that 20,000,000 API3, equal to 20% of total supply, were offered in the public token distribution and that 10,000,000 API3, equal to 10% of total supply, were sold in the seed round, implying an initial total supply of 100,000,000 API3. The cited public sources do not provide a complete filing-style launch schedule for total locked versus total unlocked supply on day one. API3 Public Token Distribution Event API3 Closes Seed Round With Six Major Funds

(b) Recipient categories & use of funds

The cited public materials identify at least these launch categories: seed investors, public purchasers, founders, partners and contributors, and an ecosystem fund distributed by the DAO. The same sources state that public-sale proceeds and unsold tokens go to the API3 DAO, that the DAO uses funds for grants and continuous operations, and that it covers operational costs for dAPIs including gas costs and API provider compensation. API3 Public Token Distribution Event The API3 Public Token Distribution Event Has Ended

(c) Initial price per token (if applicable)

API3 states that the public token distribution ran on Mesa DEX using a logit-shaped bonding curve, with an initial price of $0.30 and a ceiling price of $2.00. API3 further states that the $0.30 initial price matched the price provided to institutional investors. API3 Public Token Distribution Event

(d) Ticker / market symbol

The cited public sources identify the native token as API3. Governance API3 Public Token Distribution Event

(e) Total supply & supply regime

The cited launch materials describe an initial total supply of 100,000,000 API3, but the supply regime is not fixed. Reward-distribution materials state that mintReward mints API3 into the staking pool, that there is no predetermined staking reward schedule, and that APR moves up or down depending on whether the staked share is below or above the 40% stake target. API3 Closes Seed Round With Six Major Funds Reward calculation and distribution API3 Tokenomics Update

(f) Initial vesting / release schedules

The cited public sources state that founders and partners/contributors are subject to a 3-year linear release with a 6-month cliff, seed investors and prior investors are subject to a 2-year linear release, public tokens are unlocked, and the ecosystem fund is subject to DAO distribution. API3 also states that the founders and partners/contributors allocation was extended from a 2-year schedule to a 3-year schedule with the same 6-month cliff after the public distribution concluded. API3 Public Token Distribution Event The API3 Public Token Distribution Event Has Ended

07

Airdrop Process

Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.

  • (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
  • No airdrop planned or conducted: API3 has not conducted an airdrop and is not aware of any airdrop program associated with the project. The token distribution at launch was a public sale event conducted on Mesa DEX via a bonding-curve mechanism.

Transactions & Market Structures

08

Market Maker Agreements & Deals

Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:

  • (a) Market maker's name — the market maker's name;
  • (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
  • (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
  • (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes.

If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.

Blockworks note: The API3 team declined to provide this information due to confidentiality obligations.

09

CEX / DEX Agreements & Deals

Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:

  • (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
  • (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
  • (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
  • (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.

If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.

Blockworks note: The API3 team declined to provide this information due to confidentiality obligations.

Financial Disclosures & Risks

10

Prior Token Sales & Fundraising

Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:

  • (a) Series Name
  • (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
  • (c) Date of sale (at least month & year)
  • (d) Number of tokens sold (or % of total supply)
  • (e) Vesting schedule

If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").

  • Series Name: Seed Round API3 ClosesSeed RoundWith Six MajorFunds‘Chainlink Killer’API3 Closes$3M FundingRound WithPlaceholder andPantera
    • Investment Vehicle: SAFT
    • Date Of Sale: November 2020.
    • Number of tokens sold: 10,000,000 (10%)
    • Vesting Schedule: 2-year linear release
  • Series Name: Public Token Sale API3 Public Token Distribution Event
    • Investment Vehicle: Bonding-curve distribution
    • Date Of Sale: November-December 2020. The API3 Public Token Distribution Event Has Ended
    • Number of tokens sold: 20,000,000 (20%), delivered directly at point of purchase via Mesa DEX
    • Vesting Schedule: Public allocation unlocked; unsold tokens returned to the DAO bank.

Blockworks note: The cited public sources identify a seed round and a public token distribution event. The seed round raised $3 million for 10,000,000 API3, and the public distribution concluded after distributing the full 20,000,000 API3 public allocation and raising just under $23 million USDC. API3 Closes Seed Round With Six Major Funds The API3 Public Token Distribution Event Has Ended

11

Previous Exploits Affecting The Native Token

If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").

  • (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
  • (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
  • (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
  • (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
  • (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
  • (f) References (optional) — References (optional): link(s) to post-mortem/advisory/PR.

(a) Date & component affected

API3 states that on 2023-12-06 its AccessControlRegistry implementation used by Api3ServerV1 data feeds was identified as vulnerable, and it published the full disclosure on 2023-12-15. AccessControlRegistry Contract Vulnerability Related to OpenZeppelin Dependencies

(b) Exploit vector summary

API3 states that inheriting ERC2771Context and Multicall allowed spoofed sender addresses, which could have let an attacker spoof the Api3ServerV1 manager, grant themselves the dAPI name setter role, update their own feed with an arbitrary value, and repoint a dAPI name in a single transaction. AccessControlRegistry Contract Vulnerability Related to OpenZeppelin Dependencies

(c) Quantified impact

API3 states that the vulnerability was eliminated without ever being exploited, no user was harmed, and there was no loss of funds. AccessControlRegistry Contract Vulnerability Related to OpenZeppelin Dependencies

(d) Remediation/response taken

API3 states that it deployed new AccessControlRegistry, Api3ServerV1, and ProxyFactory contracts across Gnosis Chain, Kava Chain, Linea, Mantle, Moonbeam, Polygon PoS, and Polygon zkEVM within hours, deployed new DapiProxy contracts, and contacted known users to replace their old proxy addresses. AccessControlRegistry Contract Vulnerability Related to OpenZeppelin Dependencies

(e) Current status

API3 states that all known dAPI users had switched to the new proxies by 2023-12-10, the API3 Market was operational on the new deployments, and it stopped updating the old Api3ServerV1 contract on 2023-12-15. AccessControlRegistry Contract Vulnerability Related to OpenZeppelin Dependencies

Blockworks note: API3 has publicly disclosed one cited security incident affecting its data-feed service layer, while also stating that it did not result in loss of funds.

12

Material Risk Factors (Regulation, Technology, Token Economics)

Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.

  • (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:

  • Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?

  • Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?

  • Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?

  • Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?

  • (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:

  • Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?

  • Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?

  • (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:

  • Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?

  • Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?

(a) Regulatory, Legal & Tax Risks

API3’s public legal materials indicate that regulatory change could affect token distribution, access, and service availability because the API3 Foundation operates through a Cayman Islands legal wrapper, reserves the ability to modify or suspend services, and states that certain aspects of API3 governance may be delegated to immutable onchain DAO smart contracts. The terms also state that API3 does not operate an exchange platform, trade execution venue, custody service, money-transmission service, or clearing service. Api3 Terms & ConditionsAPI3Public Token Distribution Event The cited public source set does not provide project-specific tax guidance for tokenholders. Public legal materials instead put users on notice that they must comply with applicable law and that disputes are governed by Cayman Islands law, so tokenholders remain responsible forunderstanding their own tax obligations under their local rules. Api3 Terms & Conditions The public terms also impose user-access restrictions by requiring users not to be citizens or residents of jurisdictions sanctioned or embargoed by the United Nations or the European Union and not to be personally sanctioned or embargoed. Those restrictions create access risk for affected users and compliance risk for the project if applicable sanctions or legal requirementschange. Api3 Terms & Conditions

(b) Protocol, Technology & Security Risks

API3’s own security materials state that a data feed is an on-chain service driven by off-chain components and that Api3ReaderProxyV1 carries inherent smart-contract risk. The same materials state that feed operation depends on off-chain API providers, source-configuration choices, Merkle-root approvals, and upgradeable contracts controlled by technical-team multisigs, so implementation errors, upgrade mistakes, or feed-configuration failures coulddisrupt service or adversely affect users. Security considerations The cited public sources describe several security controls, including published audit reports, on-chain median aggregation across first-party oracle feeds, and technical-team multisig controls over upgrades and feed-configuration approvals. Those controls still have limits because the security page expressly says smart-contract risk remains inherent, and the whitepaper frames service coverage, staking collateral, and dispute-resolution design asmechanisms for handling possible malfunctions rather than eliminating them. SecurityconsiderationsAPI3: Staking Pool and DAO AuditAPI3 Public Security AuditDecentralizedAPIs for Web 3.0

(c) Token Economics, Unlocks & Incentive Risks

API3’s public token materials assume continuing demand for dAPIs, OEV capture, and staking participation. API3 states that it captures OEV and pays 80% of the associated revenue to partner dApps, while its tokenomics and reward-distribution materials state that staking rewards are used to target a desired staked share of supply and that APR is adjusted depending on whether staking is below or above the target. If demand for dAPIs, OEV capture, or staking participation weakens, utility, governance participation, and incentive alignment could weakenas well. Oracles that pay youAPI3 Tokenomics UpdateReward calculation and distribution Governance has meaningful influence over monetary policy and rewards because the DAO votes on staking incentives and collateralization, and the reward system exposes governable parameters such as stake target, APR update step, and minimum and maximum APR values. Public lockup materials also show that large categories of supply were subject to release schedules, including founders, partners/contributors, and seed investors, so governance or market changes that alter incentives, treasury flows, or staking conditions could adversely affecttokenholders through dilution, reduced rewards, or shifting token-supply overhang. GovernanceReward calculation and distributionAPI3 Public Token Distribution EventThe API3 Public TokenDistribution Event Has Ended

This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Api3 is solely responsible for the content, accuracy, and legality of its disclosures.