Skip to main content

BNB Attestation Service

BNB Attestation Service (BAS) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

BNB Attestation Service — an Infra | Identity infrastructure for attestations (verifiable statements) in the BNB ecosystem, with onchain/offchain modes (Greenfield); token (symbol: BAS) on BNB Smart Chain (BEP‑20).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a “verification and reputation layer” (attestations) for the BNB ecosystem: one can issue statements + proofs that third parties verify.
  • Who it’s for: dApps/projects and users who need to confirm KYC/identity/asset proofs and collect reputation signals.
  • Why onchain/token: attestations can be recorded onchain (public verifiability) or stored offchain in Greenfield (access control); the role of the BAS token in the product is not disclosed per Tier‑1 sources (apart from the fact that the token exists).
  • What you can actually touch (Tier‑1): BNB Passport (app) — https://www.passport.bnbattest.io/; BAS explorer — https://bascan.io/

How it works (very briefly)

  1. The user does: creates a schema and issues an attestation (or uses a dApp that does this), or confirms properties via integrations (KYC/balance/social networks, etc. — per the website).
  2. The system does: forms a “statement + proof”; depending on the mode, records the attestation onchain or stores it offchain in Greenfield with access settings.
  3. The user gets: a verifiable proof (identity/reputation/asset proof) that can be reused in applications.
  4. Where the blockchain is: onchain attestations are publicly available; offchain attestations are stored in Greenfield to provide privacy and access control (per the documentation).
  5. Token role (if any): the BAS token exists as a BEP‑20, but no Tier‑1 description of its utility within the attestation protocol was found.

Quick links: AI thesis fit

Project passport

Field Value
Project name BNB Attestation Service
Also known as (aliases) BAS; BAScan; BNB Passport; $BAS
Logo (logo) ../assets/130_bnb-attestation-service_logo.jpg
Token symbol (ticker) BAS
Category Infra | Identity
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) —
Project status (status) active
Token (standard) BEP-20
Token contract 0x0f0df6cb17ee5e883eddfef9153fc6036bdb4e37
Token model (token_type) —
Max supply 2,499,765,709.1058 BAS (Max Total Supply per BscScan)
Issuance fixed (cap)
Tokenomics (tokenomics, brief) No Tier‑1 description of the token’s utility in the protocol was found; onchain fact: a BEP‑20 token with a cap.
Governance —
Admins/keys —
Audit yes (audit PDF in the contracts repository)
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI agents applicability
Use‑case (use_case) on-chain/off-chain attestations + reputation
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 3 / 0 / 2
Last verified 2026-02-05

General project overview

BNB Attestation Service (BAS) is a standard and infrastructure for creating attestations: statements about a fact/event together with a proof that a third party can verify. Per the Tier‑1 documentation, BAS is needed to “bring” external data into Web3 while preserving privacy/data ownership: attestations can be made onchain (publicly) or offchain, stored in Greenfield with access management.

From an architectural point of view, BAS includes smart contracts (a fork of EAS) and tools for working with schemas/attestations. The product surfaces are the BAS explorer (BAScan) and BNB Passport.

Features/modules

  • Attestations (schema + resolver): the ability to define attestation schemas and issue/verify them.
  • Onchain / Offchain modes: recording attestations on the network or storing them in Greenfield (privacy/access control).
  • BAS contracts: the BAS, Schema Registry, Delegate contracts (addresses are published in the repository).
  • Explorer / Passport: interfaces for viewing/using attestations.

Typical scenarios

  • Scenario 1 (identity/KYC check): a user/project issues an attestation (onchain/offchain) → a dApp verifies the proof → uses it for access/conditions.
  • Scenario 2 (reputation): a user collects attestations from different sources → gets a verifiable set of reputation signals → applies it in airdrops/DeFi/credit scoring (as a use-case per the website).
  • Scenario 3 (privacy): an attestation is stored offchain in Greenfield → the user grants access to specific parties → control over data visibility.

Getting started (wallet/network)

  • What you need: a wallet/account for interacting with the app and the BAS contracts.
  • Network/chain: BNB Smart Chain (and also opBNB, according to the contract README).
  • Fees: onchain attestations require gas; offchain attestations — Greenfield storage fees (per the documentation).

Architecture/tech (non‑AI)

  • Components: the BAS smart contracts (fork of EAS) + Schema Registry + Delegate; SDK/docs; explorer.
  • Participant roles: attestation issuers, users (attestation owners), verifiers (dApps/third parties), schema/resolver developers.
  • Where logic runs: onchain — issuance/verification of public attestations and availability for composability; offchain — storage of attestations in Greenfield with access control.
  • Dependencies: Greenfield (offchain storage), an RPC to BNB Smart Chain, developer tools (Hardhat).

Token/economics (expanded, no forecasts)

  • Token utility: not established per Tier‑1 (the documentation focuses on attestations, not on the token’s utility).
  • Onchain fact: the BAS token — BEP‑20 on BNB Smart Chain; max supply is published on BscScan.
  • Who pays fees: onchain operations are paid for with gas; offchain storage — Greenfield fees (per the docs).
  • Issuance/burn/incentives: not established per Tier‑1 → —.

Governance

  • Who makes decisions: not established per Tier‑1 → —.
  • How protocol parameters change: via updates of the contracts/infrastructure; governance details are not disclosed → —.
  • Where decisions are discussed/made: GitHub / community channels.
  • Keys/multisig: —.

Security and incidents

  • Audits: the bas-contract repository contains contract_audit.pdf (the audit details require a separate reading of the PDF).
  • Bug bounty: no Tier‑1 found → —.
  • Incidents: not established per Tier‑1 → —.
  • Threat model: risks of forgery/compromise of attestation sources, privacy risks with offchain storage, risks of admin keys/roles in the contracts, risks of censorship/availability of the infrastructure.

Project status and timeline

  • Current status: active; the BNB Smart Chain and opBNB networks are supported (per the contract README).
  • Key releases/milestones: public addresses of the deployed contracts and the existence of the explorer/Passport.
  • Roadmap: no Tier‑1 found → —.

Ecosystem/integrations

  • Integrations: Greenfield (offchain attestations), BNB Smart Chain, opBNB; development via the SDK/contracts.
  • Partners: the website lists partners and metrics (attestations/addresses/partners).
  • Where it’s actually used: the public BAScan/Passport interfaces and the published contract addresses.

AI component of the project

  • What is real AI here? Per Tier‑1 sources, BAS contains no AI module; “AI agents” are mentioned as an area of application (intent/applicability), not as an AI component.
  • What is truly onchain? Onchain attestations are recorded on the network and are publicly available; the BAS contract addresses are published in the official repository.
  • Why is a token needed? The BAS token exists, but no Tier‑1 description of its utility (payments/staking/governance) was found.
  • Red flags (based on the information found): “AI agents” as marketing without AI artifacts; the absence of Tier‑1 token utility; the need to separately check the Greenfield access/privacy parameters and the trust model for attestation sources.

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low (intent) 1
Onchain necessity high 3
Token necessity low 0
Evidence Tier‑1 present 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 1
  • Claim (one line): the Tier‑1 description of BAS mentions “AI agents” as one of the target use-cases (area of applicability).
  • Evidence: Tier‑1 — https://www.bnbattest.io/
  • Why sufficient / why not (one line): this is intent/applicability, but not proof of an AI module → AI_0 = 1 with AI_1..AI_4 = 0.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): Tier‑1 sources describe the attestation infrastructure, but do not describe an AI component (model/inference/ML).
  • Evidence: Tier‑1 — https://doc.bascan.io/; https://www.bnbattest.io/
  • Why sufficient / why not (one line): there is no description of “what the AI does” → AI_1 = 0.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): there is a product demo (Passport/Explorer), but no Tier‑1 demo of specifically AI functionality.
  • Evidence: Tier‑1 — https://www.passport.bnbattest.io/; https://bascan.io
  • Why sufficient / why not (one line): the demo relates to attestations, not to AI → AI_2 = 0.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://www.bnbattest.io/
  • Why sufficient / why not (one line): the numbers on the website relate to the volume of attestations/addresses/partners, not to AI quality → AI_3 = 0.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): the technical description relates to the attestation infrastructure (contracts/onchain/offchain modes), not to AI modules.
  • Evidence: Tier‑1 — https://doc.bascan.io/; https://github.com/bnb-attestation-service/bas-contract
  • Why sufficient / why not (one line): there is no AI architecture/model versions → AI_4 = 0.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain (and opBNB, according to the README).
  • Addresses/identifiers: BAS token: 0x0f0df6cb17ee5e883eddfef9153fc6036bdb4e37; BAS contracts (BNB mainnet): BAS 0x247Fe62d887bc9410c3848DF2f322e52DA9a51bC, Schema Registry 0x5e905F77f59491F03eBB78c204986aaDEB0C6bDa, Delegate 0x01dAc45529a070Cb67Fc5B328a7eBE394644355B.
  • Evidence: Tier‑1 — https://github.com/bnb-attestation-service/bas-contract; https://bscscan.com/token/0x0f0df6cb17ee5e883eddfef9153fc6036bdb4e37
  • Why sufficient / why not (one line): the repository publishes the addresses of the deployed contracts, the explorer confirms the token → OC_1 = 1.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: recording attestations onchain (public verifiability) and the operation of the schema/attestation contracts; an offchain mode with storage in Greenfield for privacy/access control.
  • Evidence: Tier‑1 — https://doc.bascan.io/; https://github.com/bnb-attestation-service/bas-contract
  • Why sufficient / why not (one line): the core function of the protocol — attestations as onchain logic, not only a token → OC_2 = 1.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without a blockchain, attestations turn into a centralized database and lose the key property of public verifiability/composability without trusting the issuer/operator.
  • Evidence: Tier‑1 — https://doc.bascan.io/; https://www.bnbattest.io/
  • Why sufficient / why not (one line): the positioning as a “verification layer” implies trustless verifiability → OC_3 = 1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, BAS, on the BNB Smart Chain network.
  • Evidence: Tier‑1 — https://bscscan.com/token/0x0f0df6cb17ee5e883eddfef9153fc6036bdb4e37
  • Why sufficient / why not (one line): the explorer confirms the existence of the token → TK_0 = 0.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): No Tier‑1 description of paying for services with the BAS token was found.
  • Evidence: Tier‑1 — https://doc.bascan.io/
  • Why sufficient / why not (one line): there is no confirmation of payment utility → TK_1 = 0.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): No Tier‑1 description of staking/collateral/penalties via BAS was found.
  • Evidence: Tier‑1 — https://doc.bascan.io/; https://github.com/bnb-attestation-service/bas-contract
  • Why sufficient / why not (one line): the docs/README contain no staking/slashing mechanics for the token → TK_2 = 0.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): No Tier‑1 confirmation of governance via BAS was found.
  • Evidence: Tier‑1 — https://doc.bascan.io/; https://www.bnbattest.io/
  • Why sufficient / why not (one line): there is no description of voting/a DAO with the token → TK_3 = 0.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): without a Tier‑1 description of the token’s utility, no strict conclusion about replaceability/irreplaceability can be drawn.
  • Evidence: Tier‑1 — https://doc.bascan.io/
  • Why sufficient / why not (one line): insufficient data → TK_4 = 0 (conservatively).
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://www.bnbattest.io/ Positioning of BAS as a verification/reputation layer; onchain/offchain modes are described; “AI agents” as an area of application (intent).
Tier‑1 https://doc.bascan.io/ Official description of BAS: attestation infrastructure, onchain/offchain, Greenfield for privacy and access control.
Tier‑1 https://github.com/bnb-attestation-service/bas-contract Tier‑1 code/README: BAS contracts (fork of EAS), supported networks and addresses of the deployed contracts.
Tier‑1 https://bscscan.com/token/0x0f0df6cb17ee5e883eddfef9153fc6036bdb4e37 Onchain fact: the BAS token (BEP‑20), supply and contract.
Tier‑1 https://www.passport.bnbattest.io/ Product interface (app/demo) for using attestations.
Tier‑1 https://bascan.io Attestations explorer (public surface of the product).

No comments to display

Back to top