The development of Web3 applications is pushing blockchain beyond a simple value transfer network and toward an identity, reputation, and data network. More and more use cases need to verify real-world information, such as identity verification, enterprise qualifications, governance eligibility, and on-chain credit records. However, blockchain itself cannot directly determine whether off-chain data is true, which is why a standardized mechanism is needed to map trusted information on-chain.
BAS Attestation is a core component of BNB Attestation Service and the basic unit of the entire trust system. Whether in digital identity systems, DAO governance mechanisms, or AI Agent networks, Attestation plays an important role in establishing trust relationships.
As a digital proof record issued by a trusted entity for a specific fact, BAS Attestation can be used to record identity verification status, enterprise qualifications, DAO membership, KYC review results, on-chain behavior records, AI Agent reputation information, and more. Because all proofs follow a unified standard, they can be verified and reused across different applications.
Blockchain can ensure that data cannot be tampered with, but it cannot automatically verify whether the source of that data is real.
For example, after a user completes KYC, the blockchain cannot independently confirm whether the user actually passed identity review. Similarly, whether a company holds valid legal qualifications cannot be determined solely from on-chain transaction records.
The role of the Attestation mechanism is to introduce trusted verification parties and record their verification results on-chain in a standardized way. When a third party needs to confirm the relevant information, it does not need to repeat the review process. It can simply verify an existing proof.
This model not only improves verification efficiency, but also reduces the cost of repeated certification across different applications.
Schema is the starting point of the Attestation lifecycle.
A Schema can be understood as a proof template. It defines the data structure and field format included in the proof. Without a Schema, the system cannot determine what a specific proof record is describing.
For example, in an identity verification scenario, a Schema may include fields such as user address, certification institution, certification level, effective date, and expiration date. In an academic credential scenario, a Schema may include information such as school name, degree level, and graduation date.
Through a unified data format, different applications can read and parse proof content in the same way, enabling cross-platform interoperability.
The Attester is the proof issuer and a core participant in the entire trust system.
When a user submits a verification request, the Attester verifies the relevant information according to established rules. For example, an identity verification institution reviews the identity documents submitted by the user, an enterprise certification institution checks business registration information, while a DAO organization may verify member contribution records.
After the review is completed, the Attester creates an Attestation based on the corresponding Schema and writes the verification result into the proof data.
At this point, the Attestation includes issuer information, issuance time, and related verification data, forming a complete trusted claim.
Because an Attestation is directly linked to the issuing institution, the reputation level of the Attester often determines the credibility of the proof itself.
The Recipient is the party that receives the proof.
In most cases, the Recipient is an individual user, but enterprise accounts, DAO organizations, smart contracts, and even AI Agents can also become proof recipients.
After an Attestation is issued, the Recipient has the right to use the corresponding proof. When accessing other applications in the future, the Recipient can authorize third parties to verify the relevant proof without submitting materials again or repeating the review process.
This model allows digital identity and reputation information to move across platforms and gradually form reusable data assets.
After issuance is completed, the Attestation is recorded in the BAS registry system.
A proof record usually includes the Schema identifier, issuing institution, recipient, issuance time, and relevant data fields. Because this information is recorded on a blockchain network, it gains the characteristics of immutability and traceability.
Different applications can query the corresponding proof through a unified interface and verify whether it truly exists, whether it comes from a trusted institution, and whether it is still valid.
This unified data layer design is an important foundation for BAS to enable cross-application verification.
Verification is one of the most important stages in the Attestation lifecycle.
When an application needs to confirm a user’s identity or qualifications, the system sends a verification request to BAS and checks several key factors, including the identity of the issuing institution, the proof content, the issuance time, and the current status.
If the proof comes from a trusted Attester and has not been revoked, the verification result is usually considered valid.
Compared with the traditional model of repeatedly collecting and reviewing user materials, Attestation-based verification can significantly improve verification efficiency and reduce the risks caused by duplicate data storage.
Information in the real world is not always valid forever, so Attestations need to support status updates.
Revocation is the mechanism used to terminate the valid status of a proof. When identity verification expires, enterprise qualifications become invalid, or a user’s permissions change, the Attester can actively revoke the corresponding proof.
A revoked proof is not deleted from the blockchain, because blockchain records are permanently preserved by nature. However, the proof is marked as invalid, and during later verification, the system can recognize that it is no longer valid.
This design preserves the integrity of historical records while ensuring the accuracy of current verification results.
Overall, a BAS Attestation usually goes through the following process.
First, the developer creates a Schema to define the data structure and verification standards of the proof. Then the user submits relevant materials to the Attester, and the Attester completes the review according to the rules.
After the review is approved, the Attester issues the Attestation and writes the proof record into the BAS network. Once the Recipient receives the proof, it can authorize its use across different applications.
When a third party needs to verify the relevant information, it can directly query the BAS network to check the proof status. If the proof information changes, the Attester can update its status through the Revocation mechanism.
This entire process forms the complete lifecycle of creation, issuance, storage, verification, and revocation. It also represents the core operating logic of the BAS trust network.
Traditional verification models usually rely on each platform to review user materials separately.
Users repeatedly submit identity information across different platforms, while platforms must repeat the verification process. This not only increases operating costs, but also weakens the user experience.
BAS Attestation uses a model of one-time verification and repeated reuse, allowing verified information to be shared across different applications.
| Comparison Dimension | Traditional Verification Model | BAS Attestation |
|---|---|---|
| Identity verification | Repeated reviews | One review, reusable result |
| Data storage | Stored separately by each platform | Standardized proof |
| Information sharing | Isolated by platform | Cross-application verification |
| Traceability | Limited | On-chain verifiability |
| Automation level | Relatively low | Supports smart contract calls |
This model helps build a more open and efficient Web3 trust system.
As the core mechanism of BNB Attestation Service, BAS Attestation uses a standardized proof framework to turn real-world identity, qualifications, behavior, and reputation information into verifiable on-chain records. An Attestation begins with Schema creation, goes through Attester review and issuance, is stored in the BAS network, and is eventually verified and reused by third-party applications.
Schema is the proof template used to define the data structure of a proof. Attestation is the specific proof record generated based on that template. Without Schema, Attestation cannot support standardized verification.
Any entity with verification capability and a foundation of trust can become an Attester, including KYC service providers, enterprises, educational organizations, DAO communities, and AI Agent networks.
BAS supports both on-chain and off-chain proof models. Core verification information is usually recorded on-chain, while some data content can be stored off-chain according to practical needs, improving privacy and scalability.
A revoked Attestation is not deleted. Instead, it is marked as invalid. The verification system can identify this status and refuse to treat it as a valid proof.
Yes. The same user can hold multiple Attestations at the same time, such as identity verification proofs, academic credentials, DAO membership proofs, and on-chain reputation proofs.





