A general-purpose main network
The target main network provides deterministic EVM execution, accounts, smart contracts and AI protocol state for individuals, institutions and developers. Its independent validator rollout is not yet accepted.
ASTROBRIDGE TECHNOLOGY LIMITED / NETWORK ENGINEERING
An AI-native
blockchain network.
We are building Astro AI Chain around identity, authorization, AI tasks and verifiable results. An EVM-compatible main network and application sidechains form the target architecture. MA’s internal sidechain is one part of the wider network.
Controlled engineering preview · real-value payments are not open
01 — 02 — 03Main network / application sidechains / AI protocols
User-controlled authorizationEVM-compatible executionAI protocol designEvidence-led expansion
01 / A USEFUL FOUNDATION
One ecosystem. Distinct network roles.
AI-native is our design direction: identity, bounded permissions, tasks and resource budgets are protocol concerns. These capabilities are being developed and validated in stages.
Application sidechains
MA’s internal sidechain is an application subnetwork for its own transfer use cases. Each sidechain needs a distinct identity, resource policy and security model. Main-to-sidechain messaging and settlement require separate validation.
An AI service ecosystem
Build toward authorized AI tasks, capability discovery, measured resources and verifiable result records. Adoption and service quality will be evaluated through controlled developer pilots.
AI / PROTOCOL DIRECTION
AI needs a protocol it can safely use.
Identity, permissions, tasks and resources belong in the network design. Inference runs off-chain; consensus validates deterministic rules and recorded state. These are planned capabilities, not a claim of completed AI execution.
Identity and authorization
Versioned identities, scoped capabilities, expiry and revocation let services act within explicit user permission. Identity registration alone does not grant payment authority.
Tasks and verifiable records
Record requests, claims, result commitments and acceptance. A signature or hash can support integrity and attribution; it does not by itself prove correct inference or a truthful answer.
Resources and service quality
Develop capability directories, bounded budgets and measurable service quality. Intelligent scheduling must stay within policy and retain a tested fallback.
02 / HOW THE NETWORK FITS TOGETHER
A clear role for every layer.
Explore the target main network, AI task flow and MA sidechain. These paths explain intended roles; they do not execute a transaction or prove a completed deployment.
- 01
- 02
- 03
- 04
Each chain has its own identity and trust model.
MA is one application sidechain in the target ecosystem. A sidechain does not automatically inherit main-network security. Main-to-sidechain verification, replay protection and recovery must be tested before interoperability is enabled.
03 / OUR ENGINEERING PRIORITIES
Useful advantages, built into the design.
Main network and sidechains
Develop a general-purpose chain while retaining application-specific subnetworks. Existing access services and test components can be reused after identity, permission and availability checks.
A clear native fee model
Eligible transfers of our own approved asset inside MA target zero user fees. Production resource accounting and targeted sponsorship still need validation; infrastructure and external-chain gas are not free.
AI tasks with bounded authority
Design tasks around signed permissions, model and policy versions, deadlines and result commitments. AI can propose plans; it cannot widen authorization or bypass deterministic transaction rules.
Clear asset boundaries
Network identity, approved assets and settlement status remain explicit. An API response or bridge quote does not prove that assets have settled.
Designed to recover
Versioned releases, persistence checks and failure exercises inform rollout. Wider operation requires tested recovery, capacity and incident procedures.
Evidence over promises
Measure sustained throughput, confirmation latency, AI service quality, recovery and cost. Independent operators and security assumptions must accompany comparisons with other networks.
04 / TRUST MODEL
Verified access. Explicit trust.
Network security is built through authenticated connections, clear permissions and accountable operations. Each capability is enabled only within its approved scope.
Verify each connection
Encrypted transport and network identity checks protect authenticated requests from reaching an unintended service.
Keep authority narrow
Requests are limited to explicitly permitted capabilities. Wallet signing stays with the user; access availability does not grant payment authority.
Make failure visible
Time limits, capacity controls and explicit availability states keep failures observable. Applications must show when a requested service is unavailable.
Validate the whole payment path
Publicly trusted certificates, approved contracts, signed asset permissions, device acceptance and security review are required for a real-value payment release.
05 / THE CURRENT RECORD
Progress you can evaluate.
A dated engineering snapshot. Validated development, live network access and product acceptance represent different stages.
Live previewControlled network access
DesignMain-network architecture
PlannedAI protocol capabilities
ClosedReal-value payments
| Component | Status | What it means |
|---|---|---|
| General-purpose main network | Architecture and core engineering | EVM-compatible core design is the baseline. A separately identified main network and independent cross-region validators are not yet accepted. |
| AI task and identity protocols | Design and development | Task lifecycle, identity, capability directories and bounded intent are planned. Contract drafts and local prototypes are not production AI or audited model execution. |
| Network services | Controlled preview | Controlled authenticated read services have deployment evidence. Access locations do not establish independent blockchain validators or consensus. |
| MA application sidechain prototype | Controlled test environment | An isolated MA-oriented test chain and valueless transfer components exist. The complete main-network and sidechain connection has not been delivered. |
| MA | Separate application integration | MA is one application in the ecosystem. Gateway configuration, approved asset rules and real-device acceptance remain required; new-chain payments stay closed. |
| AstroBridge | Separate integration track | Asset catalogues, cross-chain settlement and NFT rules are validated independently by the AstroBridge team. |
Engineering snapshot: · Preview information; no SLA or benchmark claim.
06 / COST, ASSETS AND SUSTAINABILITY
A simple user experience.
An accountable operating model.
NATIVE ASSET
Zero user fee by design
Zero user fees target eligible transfers of our own approved asset in MA. Test-network zero gas is not the public resource model. Asset rules, budgets and end-to-end acceptance must precede activation.
EXTERNAL ASSETS
Respect the original network
ETH, BNB and other assets retain their original network fees and confirmation rules. Cross-chain support requires reviewed routes; no partnership or blanket fee waiver is implied.
LONG-TERM OPERATIONS
Grow responsibly
Start with controlled free access. Dedicated enterprise deployment, additional resources and service commitments may later fund operations under published terms.
A future token payment model is a roadmap decision. This page does not issue a token, offer an investment or require users to purchase an asset.
07 / DELIVERY ROADMAP
Build the foundation.
Earn the next stage.
Our long-term direction is ambitious. Each expansion depends on demonstrable engineering and sustainable operation, rather than a promised launch date.
- 01
CHAIN CORE / G1–G2
Complete the main-network foundation
Define chain identity and EVM compatibility, establish persistent cross-region validators, and validate transactions, resource controls and sustained performance. Keep the MA test ledger intact.
- 02
AI PROTOCOLS / G3
Build identity and AI task protocols
Validate authorization, revocation, capability directories, bounded intent and task states. Add real-model pilots with explicit result-quality checks.
- 03
DEVELOPER PILOTS / G4
Connect applications and sidechains
Provide versioned SDKs and tenant controls. Validate valueless main-to-sidechain messages and status checks; MA and AstroBridge integrations remain separate team responsibilities.
- 04
SECURITY AND RELEASE / G5–G6
Review before real-value use
Complete recovery, key protection, independent security review and sustainable operations. Real assets, issuance and asset bridges each require a separate release decision.
- 05
CONTINUOUS IMPROVEMENT / G7
Expand through measured demand
Add operators, regions and reviewed AI capabilities as adoption and evidence justify them. Evaluate reliability, quality and cost before widening each service.
08 / QUESTIONS WORTH ANSWERING
Understand the network before using it.
Does wider access mean that blockchain consensus is decentralized?
No. Network access, asset settlement and consensus serve different roles. Decentralization requires independent operators, governance and proven recovery.
Is every token free to transfer in MA?
No. The zero-fee design applies to eligible transfers of our approved native asset on our own chain. External chain gas, bridge fees and settlement conditions remain separate.
Can I make a real payment now?
New-chain payments are not open. The current work uses controlled previews and test assets; the MA phone payment path needs complete configuration and acceptance.
How do you evaluate reliability?
We evaluate measured availability, latency, capacity, recovery and operating dependencies. Any future service commitment must be supported by verified operational evidence.
Will Astro AI Chain be better than existing networks?
Our goal is an excellent network for practical applications. Claims about speed, cost or security must be supported by reproducible comparisons. No unmeasured superiority or absolute safety is promised.
What stays under the user's control?
Wallet signing remains user-authorized. Approved permissions, amounts, destinations and network identities must be explicit. A chat identity alone is not a verified payment address.
What does AI-native mean here?
It is our design direction: identity, bounded authorization, tasks, capability discovery and resource budgets become protocol concerns. Inference stays off-chain, and AI cannot override signatures, balances or deterministic validation. The full capability set is not yet delivered.
Is Astro AI Chain only the MA transfer network?
No. The target is a general-purpose AI-native main network with application sidechains. MA’s internal sidechain is one part. Each chain has its own trust model, and their connection needs separate validation.
ASTRO AI CHAIN
Build the network
for intelligent collaboration.
Follow our AI-native direction, the current engineering record and the next acceptance gates. Useful capabilities must earn trust through evidence.
Explore the AstroBridge ecosystem ↗