Overview
Project intent
Atomic Chain exists to move higher-frequency platform activity into a dedicated environment while Ethereum mainnet remains the higher-trust settlement and proof anchor.
Documentation hub
Atomic Chain docs
This route translates the underlying Atomic Chain documentation set into a deployable public summary. It keeps infrastructure material separate from the Atomic AI Nexus product surface while staying proof-safe.
Current framing
Roadmap concept with a full architecture set
Public claims should stay at roadmap level until testnet, bridge, security, and public evidence artifacts exist.
Core set
Start here
These are the primary architecture ideas behind Atomic Chain as currently documented.
Architecture
Layer model
Three layers define the system: Ethereum mainnet for canonical authority, Atomic Chain for app execution, and atomic-a-i.cloud for public evidence and onboarding.
Write path
Controlled execution
Writes flow through CAPPS checks first, Capsule checks for sensitive actions second, then chain logging, with important evidence anchored back to Ethereum.
Stack
Current lead
Arbitrum Orbit currently leads because it fits the hybrid permission model and Ethereum-rooted settlement story. OP Stack remains the closest fallback.
Controls
Permissions, bridge, and asset model
These summaries define how public visibility, controlled writes, and mainnet-canonical assets are meant to work.
Permission model
Hybrid access
Public evidence should remain readable, while sensitive writes require CAPPS approval and value movement requires Capsule checks.
Bridge design
Mainnet canonical, chain mirrored
DRK and wL6ETH remain canonical on Ethereum. Atomic Chain representations are mirrored execution assets rather than replacements for the originals.
Asset model
Clear token roles
DRK stays the public access rail. wL6ETH stays the protected settlement rail. Chain-side forms inherit those roles without changing their canonical source.
Sequencer model
Explicit authority first
The chain should begin with declared operator control rather than implied decentralization, with pause, upgrade, and recovery authority published openly.
Integration
DRK module wired into Atomic Chain
The DRK builder pack is now staged inside the Atomic Chain module so its contracts, AI Core tooling, profiles, bundles, and public artifacts can be reviewed as part of the same chain program.
Path
Module import
The imported builder pack lives at atomic-chain/drk-module/.
Public route
DRK module page
The imported DRK public surface is exposed under the Atomic Chain microsite.
Boundary
Separate contract sets
The imported DRK contracts stay separate from the core Atomic Chain contract set until they are reconciled intentionally.
Status
Integrated build pack
Integration does not change proof status. Public claims still require published deployment and evidence artifacts.
Delivery
Proof gates and operating rules
These gates define when Atomic Chain can move from concept language into stronger public claims.
Testnet plan
Main gate
Atomic Chain should not be described as more than a roadmap concept until public testnet deployment, bridge proof, addresses, permission proof, and evidence artifacts exist.
Security model
Narrow claims
Security claims should stay factual: layered controls, explicit bridge risk, explicit operator authority, and no implied trustlessness before the evidence supports it.
Governance
Operator-declared now
Near-term governance should be explicit, with later movement toward stronger review and control models only after the core chain program matures.
Public evidence
Artifact-first trust
Major claims should map to published chain IDs, contract references, bridge status, pause authority, and anchor records rather than narrative alone.
Boundary
How Atomic Chain stays separate
These summaries preserve the distinction between the Atomic AI Nexus platform and the Atomic Chain infrastructure concept.
Separation plan
Platform versus chain
Atomic AI Nexus remains the application and trust platform. Atomic Chain remains the proposed infrastructure layer that may later support parts of it.
Repo layout
Infrastructure ownership
Chain architecture, bridge logic, validator or sequencer planning, and chain security should live as chain materials, not as product-surface copy inside the platform repo.
Risk disclosures
Proof-safe wording
Use terms like proposed, testnet-stage, mirrored representation, and mainnet-canonical until stronger artifacts exist.
Next step
Public route plus technical build
The route is live as a documentation surface first. Testnet and bridge work come after the proof, control, and publishing model are defined tightly enough.
Decision
How DRK should work on Atomic Chain
The production choice is to bridge DRK as access and utility first, keep wL6ETH as settlement, and defer DRK-as-gas until later.
DRK
Access and utility
Bridged DRK should power CAPPS thresholds, AI Core entry, proof drops, premium routes, and fee-credit logic.
wL6ETH
Protected settlement
wL6ETH should remain the protected settlement and checkout rail rather than being collapsed into DRK.
Gas token
Not at launch
Using DRK as gas too early adds fee-pricer and batch-poster risk that slows safe production rollout instead of accelerating it.
Value path
Fastest credible route
Utility demand, route depth, and visible usage evidence are the fastest credible way to increase DRK value capture.