> For the complete documentation index, see [llms.txt](https://dataipo.gitbook.io/dataipo-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-3-positioning-and-protocol.md).
# Chapter 3 — Positioning and Protocol
SimpleChain is the native chain of AWA. It converts authoritative sources and capital actions into continuous, checkable on-chain state, and completes execution and settlement inside the same network.
## 3.1 Positioning
SimpleChain is the Trusted Asset Chain for real-world and AI-native capital. It gives DataIPO, AICOS, licensed institutions, asset managers, custodians, audit and legal service providers, developers, and authorized agents one protocol base, so that all parties work against the same asset identity, evidence set, state version, policy version, authorization, and settlement result. Sensitive data can stay inside authorized data domains; every material judgment keeps a verifiable reference and a chain of responsibility.
Protocol objects can be referenced by and interoperate with other systems, but SimpleChain mainnet is the native execution environment of this semantics: evidence anchoring, state transitions, PCT validation, and receipt registration are native transaction types of the chain, checked in stages by the consensus and execution layers, with no dependence on application contracts running on a general-purpose virtual machine.
## 3.2 Three layers, one asset state machine
Division of responsibility among AWA, DataIPO, AICOS, SimpleChain, and external authoritative sources
*Figure 2 The three-layer stack and its responsibilities*
| Layer | Role | Core duties | Boundary |
| ----------- | ------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| DataIPO | Capital formation network | Attestation, compliance, issuance, allocation; organizes assets and capital | Licensed issuance, trading, custody, and clearing rest with licensed institutions |
| AICOS | AI Capital OS | Due diligence, risk pricing, post-investment monitoring, Agent API; turns RWA into AWA | Controls no funds; makes no legal classification or final approval of its own |
| SimpleChain | Trusted asset chain | TDS, TASM, CaaS, SLC, PCT, industry oracles; proof and settlement | Creates no off-chain facts; grants no rights or compliance status automatically |
The three layers share one asset state machine. DataIPO's line is "AWA takes shape here"; SimpleChain's line is "the native chain of AWA."
## 3.3 Seven protocol capabilities
| Capability | Objects | Question answered |
| --------------------------- | ------------------------------------------- | ------------------------------------------------------ |
| Identity and credentials | Asset ID, Subject ID, Credential | Who, which asset, which account |
| Trusted evidence | EvidenceEnvelope, GranularHash, TDS | Where the fact came from, who attests, when it expires |
| Asset state | AssetStateRecord, TASM, LifecycleEvent | What the state is now, why it changed |
| Policy and compliance | PolicyProfile, CaaS, SLC | Which rule applies, which version, who approved |
| Authorization and execution | AgentAuthorization, PCT | Who may do what, within what limits, on what basis |
| Settlement and receipts | Capital Execution Engine, SettlementReceipt | Whether both legs delivered, on what evidence |
| Audit and recovery | Event graph, revocation, dispute, hold | How errors get corrected, whether history stays intact |
## 3.4 The verifiable capital loop
The nine-step verifiable capital loop from evidence to new state
*Figure 3 The SimpleChain verifiable capital loop*
Every step of the loop returns an explicit status. The evidence layer returns valid / missing / expired / revoked / disputed. The state layer returns current / stale / conflict / blocked. The policy layer returns approve / reject / manual\_review / superseded. The authorization layer returns granted / absent / revoked / over\_limit / expired. The execution and settlement layers return prepared / submitted / partially\_settled / settled / failed / reversed / disputed. Downstream systems continue only when every required stage is satisfied, and re-verify when a dependency changes.
## 3.5 How authority enters the protocol
Authority comes from formal records, statutory or contractual mandates, qualified attestors, legal documents, licensed institutions, custody and settlement accounts, and signers who can bear responsibility. The protocol binds these sources to identities, verifies signatures, controls versions, manages status, and preserves audit records, so that authority can be referenced by machines and reviewed by multiple parties. One claim may have several sources and attestors; the protocol keeps the relations, conflicts, priorities, and dispute status among claims, and the final selection of evidence rests with the applicable PolicyProfile, the contractual arrangements, and the responsible parties.
> **Architecture claim**
>
> On other chains the first-class citizen is a balance; on SimpleChain it is an asset state that carries its own evidence. The difference sits in the architecture: evidence, state, policy, authorization, execution, and receipts are native objects guaranteed by consensus rules, and the application layer cannot route around them.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-3-positioning-and-protocol.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
