Project & Team
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
BAT is presented as a blockchain-based digital advertising and attention token intended to reduce fraud and misaligned incentives in digital advertising by connecting advertisers, publishers, and users in a more direct marketplace. BAT Overview White Paper BAT FAQ
(b) Operational priorities
Public materials show ongoing operational emphasis on running Brave Rewards and Brave Ads, supporting creators and publishers, expanding BAT utility across premium services and partner commerce, and continuing Brave-operated browser and rewards services across supported regions and account types. Most recent operational priorities are set out in BAT Roadmap 3.0 (November 2024): (i) disintermediating BAT flows through the platform, (ii) expanding self-custody options for payments and contributions, (iii) growing BAT utility across Web3 and multi-chain, and (iv) launching Brave Rewards 3.0 with on-chain payouts, quests, surveys, multipliers, and a Rewards Offer Wall, introduced in 2025. BAT Overview User Terms Brave Rewards FAQ Transparency Feed BAT Roadmap 3.0 Rewards 3.0 Partner Program
(c) High-level project overview
At a high level, Brave Browser users can opt into Brave Rewards, earn BAT for viewing or interacting with privately matched ads, and use BAT for contributions, creator support, and other ecosystem uses, while advertisers use the platform to place ads and publishers or creators can receive BAT through Brave-operated services Brave browser passed 115 million monthly active users and 49 million daily active users as of May, 2026. With with a DAU-to-MAU ratio that hovers around 42%. BAT Overview Brave About User Terms Publisher Terms Advertiser Terms Verified Creator Help
(d) Primary token functions
Public sources describe BAT as a utility token used as a unit of account for advertising and attention-based services, for user rewards, for contributions to creators and publishers, and for ecosystem uses such as Brave Premium, DEX swaps via Brave Wallet, NFT marketplace use, and .brave domain purchases; the cited materials do not describe BAT as conveying governance, equity, revenue-share, or similar holder rights. BAT FAQ What is BAT and SPL-BAT BAT Overview
(e) Control surface reliance
The cited public record shows a service surface centered on Brave-operated browser, rewards, and advertising products, with access and functionality varying by region, operating system, account connection, and partner availability; no public onchain DAO or tokenholder governance control surface was identified in the cited sources. The BAT ERC-20 contract is immutable with no owner, no admin role, no mint function, no pause or freeze, and no upgrade proxy. For off-chain control, Brave Rewards backend, custodial integrations with Uphold, Gemini, bitFlyer, and ZebPay, and the Solana payout infrastructure that distributes already-bridged SPL-BAT to users is operated centrally by Brave. User Terms Brave Rewards FAQ Brave About
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.
Labs / DevCo
Full Name | Official Title | Prior Experience |
|---|---|---|
Brendan Eich Brave About BAT Overview | Founder & CEO. Brave About BAT Overview | Creator of JavaScript and co-founder of Mozilla. Brave About BAT Overview |
Brian Bondy Brave About BAT Overview | Founder & CTO. Brave About BAT Overview | Formerly of Khan Academy and Mozilla. Brave About |
Luke Mulks Brave About BAT Overview | VP, Business Operations; co-author of the BAT whitepaper. | Background in ad-tech; host of The Brave Technologist podcast. |
Yan Zhu Brave About BAT Overview | Chief Information Security Officer | Senior staff technologist at the Electronic Frontier Foundation worked on HTTPS Everywhere, Privacy Badger, and the Let's Encrypt core team. |
Labs/DevCo
Foundation No foundation entity exists for BAT. DAO/Onchain Governance No DAO or onchain governance entity exists for BAT.
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 on-chain 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., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
No DAO or onchain governance entity exists for BAT.
(b) Contract/admin powers
No DAO or onchain governance entity exists for BAT. The BAT ERC-20 contract is verifiable on-chain and is non-upgradable, non-mintable, with no privileged admin role; after the ICO finalized no party can mint, freeze, blacklist, or pause BAT on Ethereum. BAT Overview User Terms Advertiser Terms
(c) Locked-token rights (conditional)
No DAO or onchain governance entity exists for BAT.
(d) Value accrual & holder rights
No DAO or onchain governance entity exists for BAT.
(e) Dissolution authority
No DAO or onchain governance entity exists for BAT.
No DAO or onchain governance entity exists for BAT.
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
No foundation entity exists for BAT.
(b) IP ownership & control
No foundation entity exists for BAT.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No foundation entity exists for BAT.
(d) Powers over DevCo
No foundation entity exists for BAT.
(e) Contract/admin powers
No foundation entity exists for BAT.
(f) Current economic arrangements and distribution policies
No foundation entity exists for BAT.
No foundation entity exists for BAT.
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
Brave Software International SEZC is identified in the cited terms as a Cayman Islands company. User Terms Publisher Terms Advertiser Terms
(b) IP ownership & control
BAT ownership and IP are controlled by Brave Software International.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No DAO or onchain governance entity exists for BAT.
(d) Powers over Foundation
No foundation entity exists for BAT.
(e) Contract/admin powers
The BAT ERC-20 contract is immutable with no owner, no admin role, no mint function, no pause or freeze, and no upgrade proxy. For off-chain control, Brave Rewards backend, custodial integrations with Uphold, Gemini, bitFlyer, and ZebPay, and the Solana payout infrastructure that distributes already-bridged SPL-BAT to users is operated centrally by Brave. User Terms Brave Rewards FAQ Brave About
(f) Current economic arrangements and distribution policies
Brave users who participate in Brave Ads receive 70% of advertising revenue in BAT purchased with advertiser dollars or other fiat currency. Transparency Feed
The cited public record identifies Brave Software International SEZC as the operating company for Brave Rewards services and as a Cayman Islands company. User Terms Publisher Terms Advertiser Terms
Token Supply & Allocations
Initial Allocation
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch. Include: (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).
Launch Supply Totals | Recipient Categories & Use of Funds | Initial Price per Token | Ticker / Market Symbol | Total Supply & Supply Regime | Initial Vesting / Release Schedules |
|---|---|---|---|---|---|
The cited sale materials describe a 1.5 billion BAT launch supply, with up to 1 billion BAT | | Recipient Category | Allocation | Publicly Described Use | | Public sale disclosures state that 1 ETH purchased 6,400 BAT, equal to 0.00015625 ETH per BAT The sale opened at 8AM PST on May 31, 2017 at Ethereum block 3,798,640. BAT FAQ Token Sale Terms White Paper | The cited materials describe BAT as having a total supply cap of 1.5 billion tokens with no | Public sources state that sold BAT were immediately transferable, the development pool was
|
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").
(c) No airdrop planned or conducted
No airdrops have been conducted for BAT.
Transactions & Market Structures
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.
No active or historical market maker agreements exist for BAT.
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.
The Brave team declined to disclose any active or historical CEX / DEX agreements or deals.
Financial Disclosures & Risks
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 | Investment Vehicle | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
Public BAT Token Sale Sale OverviewWhite PaperBAT FAQ | Direct Crowdsale | 2017-05-31 | 1,000,000,000 BAT sold, equivalent to 156,250 ETH. | Public sources state crowdsale tokens were immediately transferable, with no lockup except for the development pool. |
BAT explicitly states no follow-on BAT sale is planned. Brave has purchased BAT on the open market via Gemini, Uphold, and Coinbase to fund Brave Ads payouts; these purchases are disclosed at the Transparency Feed. BAT FAQ, Transparency Feed.
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) — Link(s) to post-mortem/advisory/PR.
The BAT ERC-20 contract has not been exploited; the Wormhole-bridged SPL-BAT contract on Solana has not been exploited; and Brave Rewards' custodial settlement infrastructure (Uphold, Gemini, bitFlyer, ZebPay) has not had a publicly disclosed compromise affecting BAT custody. Brave operates a public HackerOne bug-bounty program. Brave on HackerOne, BAT contract on Etherscan
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
Brave Rewards access and functionality can vary by region, provider availability, and legal restrictions, and some countries are not eligible to participate in Brave Rewards. User Terms Brave Rewards FAQ The user, publisher, and advertiser terms also condition use on compliance with applicable law, embargo and sanctions restrictions, and required licenses or governmental authorizations. User Terms Publisher Terms Advertiser Terms BAT-specific disclosures further state that BAT is not intended to be a digital currency, security, commodity, or similar financial instrument and that users remain responsible for determining and remitting applicable taxes. BAT FAQ Token Sale Terms What is BAT and SPL-BAT
(b) Protocol, Technology & Security Risks
The BAT and Brave Rewards surface depends on Brave browser and rewards infrastructure, partner wallet or custodial integrations, privacy-preserving ad matching, and anti-fraud controls, which means implementation, logging, or partner-integration failures can affect user balances, reward flows, or platform availability. BAT Overview User Terms Browser Privacy Notice The July/August 2020 brave://rewards-internals incident shows that BAT-related logging mistakes could expose sensitive reward-linked credentials, even though Brave reported fixes, token invalidation, and no known malicious use or real impact from the August case. 2020 Incident Brave's engineering policy also states that work related to money, BAT, cryptography, sensitive user information, and logs sent to Brave or third parties requires security/privacy review, which indicates an acknowledged operational security surface that still depends on review discipline and implementation quality. Security Reviews
(c) Token Economics, Unlocks & Incentive Risks
BAT has a fixed 1.5 billion supply, over 99% of which BAT says is already in circulation. BAT Overview Sale Overview BAT utility and reward flows also depend on continued advertiser spending, Brave-operated rewards mechanics, partner integrations, and the programmatic use of advertiser dollars or other fiat currency to purchase BAT for rewards, while users in Brave Ads receive 70% of advertising revenue according to the transparency feed. Transparency Feed Brave Rewards FAQ Public sale materials also show that launch-era distribution included a user growth pool and development pool with structured release conditions, which means historical allocation design and platform incentive policy remain relevant to BAT's economic profile. Sale Overview BAT FAQ Token Sale Terms
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. Basic Attention is solely responsible for the content, accuracy, and legality of its disclosures.