A-Network
Technical Whitepaper

Version 3.6 — AnetSwap Governance Hardening

Version 3.6 lands the second half of the AnetSwap audit pass: the contract's administrative surface is now restructured to match AnetBridgeVault, retiring the single-owner() model in favor of a three-role split with a 48-hour timelock on every parameter change. This is the on-chain prerequisite for scorecard milestone #6 (AnetSwap multisig + timelock).

Governance model (new)

Timelock semantics

• TIMELOCK_DELAY = 48 hours — admin must wait this long after schedule…() before execute…() succeeds.
• EXECUTION_GRACE = 14 days — a scheduled change becomes permanently expired 14 days after its ETA. This prevents a stolen admin key from cashing in on a stale, community-tolerated schedule months later. Same primitive as the vault.
• Bait-and-switch resistance — execute…() takes the same arguments as schedule…() and re-hashes them with keccak256(abi.encode(…)); any mismatch reverts. Admin cannot announce a benign value and execute a malicious one.
• Cancellable — admin can drop any pending change via cancelChange(id) at any point before execution.

API summary

• Timelocked param changes (schedule→wait 48h→execute): FeeBps, FeeRecipient, ConfigureToken, Unpause, Pauser, Operator.
• Instant (no timelock): pause (pauser or admin), markProcessed / batchMarkProcessed (operator or admin), withdrawNative / withdrawToken (admin-only, destination hard-wired to admin).
• 2-step admin handover: transferAdmin(newAdmin) proposes, acceptAdmin() finalises from the new address. transferAdmin(0) cancels.
• Compatibility shim: owner() still returns admin so existing tooling (Etherscan “Read”, off-chain indexers, the v3.5 ABI) keeps working.
• New events: AdminTransferProposed, AdminTransferred, PauserUpdated, OperatorUpdated, ChangeScheduled, ChangeExecuted, ChangeCancelled.

Deployment & migration

• New constructor signature: AnetSwap(admin, pauser, operator, feeRecipient). Deploy script (scripts/deploy.js) reads ANET_BRIDGE_ADMIN, ANET_BRIDGE_PAUSER, ANET_BRIDGE_OPERATOR, falling back to ANET_BRIDGE_OWNER then to the deployer EOA. Each fallback emits a warning.
• Token whitelist script (scripts/setup-tokens.js) now runs in two phases: TOKEN_SETUP_PHASE=schedule stages every token change and writes a state file; TOKEN_SETUP_PHASE=execute replays them after the 48-hour delay.
• The currently-deployed BSC contract 0x1A1AFE5BF1ffDB64aC10958cCe2D06B22Fb47Fb8 is the v3.5 build. Migration to the v3.6 governance contract is on the roadmap and requires a fresh deploy + bridge-state migration. Until that ships, scorecard milestone #6 sits at In Progress (code complete, deploy pending).

Testing

37 new Hardhat tests cover the role split (pauser cannot unpause, operator cannot move funds, stranger cannot do anything), 48h timelock on every parameter, bait-and-switch resistance, the 14-day grace window, cancellation, and the 2-step admin handover. Combined with the 33 existing AnetBridgeVault tests, the contracts repository now passes 70/70 green.

Fee-on-transfer token accounting and entry-side rolling-24h caps remain on the backlog (carried over from v3.5) and will land in v3.7.

Version 3.5 — AnetSwap Hardening Pass

Version 3.5 documents an internal security & correctness audit performed on the AnetSwap entry-side contract and the immediate fixes that were applied. The audit was conducted under a deliberately adversarial frame — cryptographic rigor in the spirit of Satoshi Nakamoto, with engineering review for gas, ERC-20 edge cases, and DoS surface. The companion AnetBridgeVault (v3.3) was re-reviewed and required no code changes; its 2-of-3 EIP-712 release path, true 24-slot rolling cap accounting, high-s signature rejection, strictly-ascending unique-signer enforcement, and 48h admin timelock all passed without finding.

Fixes applied to AnetSwap.sol (BSC 0x1A1AFE5BF1ffDB64aC10958cCe2D06B22Fb47Fb8)

Outstanding hardening backlog (acknowledged, not yet patched)

• Fee-on-transfer / rebasing token accounting (Medium). swapTokenForAnet currently uses the user-supplied amount for net accounting. Tokens that take a transfer tax would result in over-credit on Layer 1. Planned fix: measure balanceOf(this) delta before/after safeTransferFrom and credit the actual received amount.
• Entry-side rolling caps (Medium). AnetBridgeVault enforces per-tx / per-recipient-24h / global-24h caps on the release side. AnetSwap currently has only per-token min/max. Planned fix: mirror the vault's rolling-24h pattern on the entry side so a backend compromise cannot be drained as fast as users send.
• Deployer key rotation (operational High). The plaintext DEPLOYER_PRIVATE_KEY_BSC on the deployment workstation must be rotated to a hardware-wallet or Safe-owned deployer flow. Git history is clean (.env is gitignored and was never committed), but disk-resident plaintext is not the standard A-Network is held to.

Items confirmed sound (no change required)

• AnetBridgeVault EIP-712 domain pins chainid at construction; release path verified end-to-end.
• High-s rejection constant in _recover equals secp256k1_n / 2 exactly.
• rescueOtherToken cannot be tricked into transferring the vault's own wANET (the token whose transfer is called is the passed token, not wANET).
• Hardhat config refuses placeholder keys and refuses silent fallback — per-chain deployer key required.
• pi-backend has strict CSP, rate limits, IP allowlist on admin routes, and timing-safe admin-key comparison.

The fix commits and the full audit report are tracked in the contracts repository. The next whitepaper bump (v3.6) will record the fee-on-transfer and entry-side cap fixes, and milestone #6 (AnetSwap multisig + timelock) on the decentralization scorecard.

Abstract

A-Network v1.0.6 defines a proof-of-time ledger backed by fixed 6-hour Ant Work sessions and a live ANTS Mainnet. Session completion credits ANTS, the smallest accounting unit of the Layer 1 economy. Spendable Layer 1 ANET is not issued at session end and becomes claimable only after a participant reaches 1,000 completed sessions.

Today, mining accrual is performed exclusively through an authenticated server-side attendance check-in (POST /mining/start). The mobile app does not perform any on-device proof-of-work, hashing, or background compute — it simply opens a 6-hour attendance window and the backend updates the ledger. Phase 5 (decentralized signed SHA-256 proofs) remains on the research roadmap (see Section 11 — Phase 5 Roadmap) and is not active on the production network in v1.0.61 (123). When it ships, it will run alongside server-approved mining, not replace it.

The system uses two distinct assets. The Web3 utility token is a fixed-supply 21,000,000 ANET asset on BNB Chain. The Layer 1 coin economy uses ANTS as its operating unit and Layer 1 ANET as its settlement unit. One ANET = 100,000,000 Ants. This preserves precision and keeps the mining ledger compatible with future fee and settlement rules.

The Layer 1 mining schedule follows a Bitcoin-like halving rule with a preserved launch tranche. The first 500,000 total completed sessions use a launch output of 0.04882812 ANET-equivalent per session. After that tranche, the long-life schedule begins at 0.00262144 ANET-equivalent per session and halves only as the network reaches defined session milestones. Registration count, colony size, and wallet balance do not affect issuance.

The BNB Chain utility token is documented as a 50% / 50% founder stewardship pool, held between two named co-founders — @Joel_Dupalco (Coach Joel) and @Digitalgold1979 — for ecosystem utility, distribution planning, AMA rewards, liquidity provisioning, and Layer 1 access rails. As of May 24, 2026, the BEP-20 contract itself has no on-chain owner: the deployer wallet permanently renounced ownership, so the founders hold tokens as ordinary holders with no administrative privileges over the contract. By contrast, the Layer 1 mining coin has no owner allocation and no founder allocation: participants enter through work, not insider minting.

Once the mining hard cap is reached, the issuance engine enters an issuance-ended state. No further mining output is minted, no new issuance-bearing sessions start, and claim routes cannot create new Layer 1 ANET beyond the cap tracked by the mining ledger. The network remains active for identity, wallet continuity, migration, and future fee-based activity.

The roadmap currently targets a broader Layer 1 release window in roughly 8 months, subject to engineering readiness. Project planning may reference an illustrative early price zone around $0.000001 for initial Layer 1 market discovery, but that is not a guaranteed launch price and actual valuation will be determined by open market participation.

The live backend is also hardened for public-scale participation. Growth-critical counters and identifiers use 64-bit integer space, and registration is proxy-aware so users sharing the same carrier, school, office, or Render edge network are not falsely blocked purely because they appear behind a common upstream IP.

A-Network deliberately excludes referral-based issuance. Ant Codes are colony links only. They do not create coin bonuses, session credits, percentage commissions, or multi-level rewards. Every unit in the Layer 1 mining economy must arise from completed Ant Work sessions and pass through the governed claim flow.

Version 2.3 Protocol Update — Unified Miner Lifecycle Enforcement

Version 2.3 defines a single mandatory lifecycle for all participants and system modules. The objective is policy consistency across mining, DEX settlement, transfer access, and NFT identity utility. The rule is strict and global: mine first, complete 1,000 verified sessions, execute first successful authenticated settlement event, then unlock NFT profile capability.

State Machine Definition

Protocol Invariants

• Invariant 1: NFT profile cannot be first-created before first successful settlement event.
• Invariant 2: Web DEX remains read-only for market data; settlement execution is mobile-wallet only under eligibility and security controls.
• Invariant 3: First successful DEX execute acts as NFT activation trigger for that ANET profile identity.
• Invariant 4: Marketplace ownership transfer only occurs through settled listing actions.
• Invariant 5: Domain-auction policy remains strict: .ant asset identity plus minimum bid threshold.

Protocol Invariants v1 (Canonical Production Set)

This canonical set defines non-negotiable production guarantees for settlement, cashout automation, and identity activation. Any implementation, upgrade, or operator action that violates these rules is considered non-compliant with protocol policy.

• PI-1 (Policy Gate): No swap/transfer/cashout settlement executes unless eligibility policy checks pass at execution time.
• PI-2 (Single Activation Trigger): First-time NFT profile activation occurs only after at least one successful authenticated settlement event.
• PI-3 (Execution Separation): Public web interfaces may expose market data and quotes, but authenticated execute paths remain wallet-gated.
• PI-4 (Idempotent Settlement): Duplicate payout execution for the same request identifier is forbidden across retries, restarts, and worker cycles.
• PI-5 (Dual Audit Evidence): Successful payout must produce both settlement-chain evidence (tx hash) and ANET activity evidence (payout_sent event).
• PI-6 (Deterministic Queue State): Payout records transition only through valid states (pending -> paid/failed/duplicate) and remain replay-safe after crashes.
• PI-7 (Key Isolation): Production execution uses signed-only flow; seed phrase and private key material are never transmitted through public API requests.
• PI-8 (Risk Envelope): Hourly caps, per-user daily limits, reserve-ratio checks, and retry limits are mandatory controls, not optional runtime features.

NFT Marketplace Governance (v2.3)

The integrated marketplace supports fixed listings, auction listings, and domain-auction listings. Domain auctions are treated as a special policy class for identity namespace assets and include explicit constraints.

Implementation Notes for v2.3

Automated Cashout Pipeline (Production Addendum)

A-Network now operates an automated payout pipeline for cashout-eligible users. The design keeps execution automatic while preserving deterministic safety controls. Eligibility and settlement remain policy-gated, and every payout continues to produce an auditable trail across both networks.

Pipeline Guarantees

• Automatic ingestion: payout candidates can be fetched from an authorized backend feed each worker cycle (no manual queue editing required in production mode).
• Queue as safety ledger: each payout moves through pending -> paid/failed/duplicate states, enabling crash recovery and replay-safe retries.
• Idempotency: request_id and swap_reference are enforced to prevent double-settlement on retries or restarts.
• Risk controls: hourly cap, per-user daily cap, reserve-ratio threshold, and wallet eligibility checks remain mandatory.
• Dual audit output: successful payout writes BSC transaction hash and an ANET on-chain AppActivity event (action=payout_sent).
Ops
Consistency Rule Automation does not bypass policy. It removes manual operations while preserving deterministic controls and immutable audit evidence.
• Backend policy endpoint now exposes explicit NFT activation semantics in addition to no-burn and domain auction parameters.
• Public web DEX interfaces provide view and quote functions; execute functions are gated to authenticated mobile-wallet flows.
• DEX execute path records settlement request state and can auto-provision cashout-activated NFT profile identity if absent.
• NFT profile first creation gate validates cashout/swap activation condition instead of requiring pre-trade NFT registration.
• Marketplace list view supports board segmentation including domain-auction-focused board filtering.

Future External Exchange Path

The v2.2 architecture remains compatible with future third-party rails (including centralized exchange and institutional integration models) by design. External channels are treated as integration layers on top of existing identity, listing, and settlement primitives rather than replacement logic.

• External listing/index APIs can mirror marketplace inventory while preserving on-platform ownership authority.
• Webhook/event relays can stream listing creation, bid settlement, and final transfer states to partners.
• Custodial buyer support can be added as an adapter layer without modifying core miner lifecycle invariants.
• Compliance overlays (regional, KYC, sanctions filters) can remain optional and integration-specific.

Introduction

The Failure of Web2

Most large Web2 systems treat user activity as platform-owned output. Time, attention, and behavioral data are monetized by the operator, while the participant typically receives neither ownership nor a verifiable claim on the resulting network value.

These systems also lack a common scarcity model and do not expose a public settlement layer. Participation may be measured internally, but it is not usually portable, auditable, or directly attributable to the participant in a durable ledger.

The Partial Solution of Web3

Web3 introduced public ownership records and programmable settlement. However, many systems remain capital-weighted, operationally complex, or vulnerable to Sybil behavior. Access often depends on prior wallet literacy, gas management, or direct capital exposure.

Ownership visibility alone does not solve the question of fair entry. A network may publish balances on-chain while still concentrating early access in a narrow class of participants.

The A-Network Proposal

A-Network proposes a staged system. The first stage uses a smartphone-accessible proof-of-time ledger. The second introduces public token visibility on BNB Chain. The third extends the ledger into a Layer 1 settlement environment. The long-term direction is ANET Core, where identity, governance, and application logic can be built on top of the participation record.

In this model, completed 6-hour sessions are the basic unit of contribution. The ledger is intended to persist across later phases rather than being discarded at each upgrade.

The Vision

A-Network is structured as a long-horizon infrastructure project. The present mobile ledger is treated as an entry layer, while later phases are intended to extend that ledger into broader settlement, fee, identity, and governance systems.

Web2 vs Web3 vs Web4 vs ANET Core

Coin Model — Utility Token + Layer 1 Mining Coin

A-Network separates its asset design into two linked but distinct layers. The first is the Web3 ANET utility token on BNB Chain, fixed at 21,000,000 ANET and held as a 50% / 50% co-founder stewardship pool between @Joel_Dupalco and @Digitalgold1979. The BEP-20 contract itself is ownerless as of May 24, 2026 (owner = 0x0); the stewards hold tokens but cannot mint, pause, or blacklist. The second is the Layer 1 mining economy, where users accrue ANTS through verified participation and become eligible to convert into spendable Layer 1 ANET only after the 1,000-session threshold.

The Web3 utility token serves as the ecosystem utility layer and an external access rail. The Layer 1 coin economy is intentionally different: it is specified as 100% mining-based, with 0% founder allocation and 0% owner allocation. The distinction is deliberate. Stewarded utility supply and miner-earned settlement supply are not treated as the same asset class.

Ants — The Smallest Unit of ANET

In Bitcoin, the smallest indivisible unit is called a Satoshi (or Sat), where 1 BTC = 100,000,000 Satoshis. A-Network adopts the identical precision model but with its own cultural identity.

Supply Exhaustion & Hard Cap Enforcement

The MAX_SUPPLY constant is hardcoded in the Ant Work engine at exactly 21,000,000 ANET-equivalent units for the Layer 1 mining ledger. Session completion adds only ANTS to the user ledger. Supply protection becomes critical during claim, where a user's convertible ANET is capped so that totalANETClaimed can never exceed the mining-ledger cap.

In v1.0.6, hard-cap enforcement is not limited to conversion math. The live backend explicitly switches to an issuance-ended state when supply is exhausted: issuance-bearing session starts are refused, legacy minting routes return issuance-ended responses, and no new ANET can be created beyond the cap.

Dual Economic Architecture

A-Network operates two economically distinct systems that coexist without conflating their roles. Understanding the separation between them is essential to understanding how value, supply, and liquidity work in the network.

Layer 1 — Closed-Loop Utility Economy

The Layer 1 economy is denominated entirely in ANTS, the smallest unit of the network. All accounting, fee calculation, reward issuance, and session crediting happens in ANTS. There is no external price oracle or market feed in Layer 1; value is derived from utility, participation, and the network’s own fee and distribution mechanics.

• All session rewards are credited as ANTS.
• Mining output and fee models are defined in ANTS.
• The block explorer records ANTS-denominated balances and transactions.
• ANTS functions as the gas unit for the planned smart contract layer.
• Settlement/cashout can occur only through authorized bridge and DEX execution flow under policy controls.

Spendable Layer 1 ANET is a higher-denomination representation. 1 ANET = 100,000,000 ANTS. This ratio is fixed. Conversion from ANTS to spendable ANET is available once a participant reaches the 1,000-session genesis threshold.

Web3 — Open-Market Economy (BNB Chain)

The Web3 side of the ecosystem consists of a fixed-supply 21,000,000 ANET BEP-20 token deployed on BNB Chain. Unlike the Layer 1 economy, the Web3 token operates under open market conditions: its price is determined by decentralised exchange liquidity, order flow, and trader activity.

• Total supply: 21,000,000 ANET — fixed, no minting.
• Listed on DEX (PancakeSwap / BSC ecosystem).
• On-chain market data visible at: DexScreener → ANET/BSC
• The Web3 token provides external liquidity and market price discovery for ANET independent of the closed-loop Layer 1 system.
• Web3 token allocation follows a founder-stewardship model distinct from Layer 1 mining distribution.

Value Formation

User Transparency

• KYC: KYC is not required at the protocol level. External fiat on/off-ramp services, if used, may impose their own KYC requirements independently of A-Network.
• Web3 token risk: The BEP-20 ANET token operates under independent market conditions. Price, liquidity, and availability are not controlled by A-Network.
• Layer 1 and Web3 are separate: Holding or trading the Web3 BEP-20 token does not grant Layer 1 mining rewards, and Layer 1 mining does not guarantee Web3 token value.
• No buy-to-mine shortcut: Acquiring Web3 ANET does not unlock or mint native mined ANET; real Layer 1 coin participation remains tied to verified mining lifecycle and eligibility thresholds.
• Fee-based miner rewards: Eligible miners may receive protocol fee distributions tied to verified network activity and governance rules. These distributions are variable and are not guaranteed returns.

Smart Contract Vision

A planned future phase of A-Network (Phase 4 in the roadmap) introduces a smart contract layer directly on Layer 1. This section describes the architectural intent, the role of ANTS as gas, and the implementation approach under evaluation.

ANTS as Gas

In the planned smart contract model, ANTS serves as the gas unit for smart contract execution on Layer 1. This aligns execution cost with the native unit of the network’s economy, keeping fees denominated in the same asset used for mining rewards and balances.

• Every contract call consumes a defined quantity of ANTS as an execution fee.
• Gas fees flow back into the network’s fee distribution model, contributing to ecosystem sustainability.
• Miners and validators benefit from gas fee distribution in addition to block rewards.
• ANTS-denominated gas keeps the cost model independent of external token markets.

Implementation Approach

Web2 Phase — Time-Based Mobile Ant Work

The Web2 phase is the entry point into the system. It requires a smartphone and internet access, but no GPU mining, staking capital, or specialized hardware. In v1.0.6, the backend functions as a server-validated ledger that records time-based contribution, ANTS accumulation, eligibility progress, delayed ANET conversion, wallet continuity controls, migration-ready account state, the preserved 500,000-session launch tranche, and 64-bit-safe counters for public-scale participation.

The 6-Hour Ant Work Cycle

Ant Work in A-Network is structured around fixed 6-hour sessions. Each session is a discrete unit of validated participation. A user begins a session, waits 6 hours, and completes it. On completion, the ledger credits ANTS rather than immediately issuing ANET. The session duration cannot be shortened, and instant completion attempts are rejected.

Session Capacity Rules

Prerequisites for Ant Work

App Delivery & Monetization

The mobile client also contains delivery infrastructure that is operationally useful but economically secondary. Notifications and advertising do not alter the distribution rules. The backend remains the sole source of truth for ANTS crediting, session eligibility, and ANET conversion.

Session Halving — The v1.0.6 Launch-Tranche Distribution Formula

A-Network v1.0.6 preserves the original launch economics for the first 500,000 total completed sessions, where each completed 6-hour session earns 0.04882812 ANET. After that launch tranche, the long-life schedule begins at 0.00262144 ANET per session and halves each time the network reaches another 3,800,000,000 post-launch sessions. The controlling variable is total verified network activity.

This design keeps the curve predictable and auditable. A user cannot alter the reward stage through colony size, coin purchases, or wallet size. Reward progression is driven only by aggregate proof-of-time across the network.

Dashboard interpretation: current mining output can be displayed in ANTS because ANTS is the smallest live accounting unit of ANET. Users may also see an estimated ANET equivalent, but the ledger source of truth during Web2 remains ANTS accumulation until claim eligibility is reached.

The Halving Level Formula

Important metric distinction: Eligibility and halving are now separate concepts. A user becomes eligible to convert after 1,000 sessions, but halving progression is driven only by totalSessions at the network level.

Threshold Milestones to the Next Halving Stage

Complete Distribution Table

The v1.0.6 distribution table preserves the original launch economics for the first 500,000 total sessions, then moves onto a slower post-launch curve. There is one launch tranche followed by ten post-launch stages, from Stage 0 to Stage 9, with each post-launch stage halving the session output.

Sessions Required to Exhaust Supply

Anti-Gaming, Fraud Detection & Enforcement

Because issuance depends on verified sessions, the mining ledger must assume attempted automation, multi-accounting, and session manipulation. The defensive model is layered: preventive controls, risk scoring, heartbeat validation, pattern detection, and admin enforcement.

Layer 1 — Preventive Controls

These controls are intended to block the most common abuse paths before reward calculation occurs. They do not replace later checks; they reduce the number of invalid sessions that reach later stages of the pipeline.

Layer 2 — Real-Time Risk Scoring Engine

Every mining action passes through a multi-signal evaluation pipeline that computes a cumulative risk score per account. When that score reaches a configured threshold, mining actions are blocked. Risk points persist across sessions.

Layer 3 — Heartbeat Validation & Bot Pattern Detection

Active sessions are monitored through a heartbeat protocol. The server tracks heartbeat timing and count for each session. Sessions that diverge from the expected pattern may be flagged or terminated.

Layer 4 — Security Audit Logging

Significant mining events are recorded in a dedicated security_audit_logs table. The log is intended for forensic review and enforcement support.

The audit log is indexed by user_id, event_type, and created_at. Admin endpoints surface these records alongside user profiles.

Suspicious Activity Tracking

In parallel with the risk score, a separate suspicious_flags counter records explicit rule violations per account.

Layer 5 — Fraud Cluster Detection & Bot Cleanup

The backend also provides admin-only endpoints for cluster analysis and cleanup. These tools are not fully automatic; they are intended to support manual investigation and controlled enforcement.

Admin Dashboard — Eligible Users & Cheater Detection

Admin users identified by ADMIN_USER_IDS have access to a restricted dashboard suite through the /admin route prefix. All admin endpoints require JWT authentication and explicit admin verification.

Account Ban & Enforcement System

The ban system is manual. No user is permanently banned by an automated rule. The system provides both ban and unban operations for admin use.

Mining Session Statuses Reference

Every mining session in the mining_sessions table carries a status that reflects its lifecycle outcome:

Configuration Reference

All anti-abuse thresholds are configurable via environment variables, allowing the network operator to tune sensitivity without code changes:

Web3 Phase — BNB Chain Integration

Web3 serves as the utility and visibility bridge between the Ant Work ledger and external crypto infrastructure. In the current system, Web2 remains the source of truth for sessions and ANTS accumulation, while BNB Chain provides public contract visibility, wallet references, and the external utility token used for longer-term access planning.

ANET Token Contract

Wallet Identity & Migration Address

Each account can create a unique ANET wallet identity in-app. This wallet is linked to the miner profile and is used to display the user's currently claimed ANET coins while also preserving tracked ANTS for migration visibility.

Users can also save a separate migration wallet address for future Web4 Layer 1 migration. This allows migration planning ahead of chain launch while preserving mining continuity and future identity portability.

Users connect a Web3 wallet address only as a destination for controlled distributions or migration routing. A Network does not store private keys and does not ask for seed phrases to define wallet ownership. In the current release, wallet continuity is protected by layered controls: an optional wallet PIN, encrypted server-side seed continuity storage for in-app wallet recovery, email OTP verification before seed reveal, and backward-compatible local fallback support for older users whose legacy seed was never migrated to encrypted storage.

v3.0 — In-App EVM Bridge (AnetSwap)

Version 3.0 (May 2026, app v1.0.21+71) introduces a fully self-contained EVM bridge inside the mobile wallet. Users can swap BNB, USDT, or USDC directly into ANET on BSC mainnet without leaving the app and without installing MetaMask or any external wallet.

v3.1 — L1 → BSC Return Bridge (Burn Endpoint)

Version 3.1 (May 2026) closed the bridge loop. The ANET Layer 1 node exposes POST /bridge/burn, allowing a user to burn native Layer 1 ANET in exchange for an equivalent amount of wANET (BEP-20) on BSC mainnet. Each burn is authorized by a signed action authorization (ECDSA over the user’s L1 wallet key), recorded immutably on the L1 chain, and exposed through GET /bridge/burns for off-chain consumption. Version 3.3 (May 25, 2026) hardens the release side: wANET is no longer disbursed by a trusted relayer key but instead by the on-chain AnetBridgeVault contract (0x31438362a7667ce5559500023D025c7c14168B49), which requires a 2-of-3 EIP-712 signature threshold from independent self-hosted signers before any release. The relayer process retains only the gas-paying submitter role and has no signing authority; see § v3.3 below.

v3.3 — AnetBridgeVault (2-of-3 EIP-712 Smart-Contract Bridge)

Version 3.3 (May 25, 2026) removes the bridge from the trusted-relayer model and pins it to an on-chain smart contract with an independent multi-signer policy. The previously hot-EOA wANET escrow has been replaced by AnetBridgeVault, a one-way-sink contract whose release function requires a 2-of-3 EIP-712 signature threshold from three independent, self-hosted signers. The bridge submitter wallet pays gas only and holds no signing authority; it cannot release a single wANET on its own. Even the vault admin cannot remove wANET from the contract: an explicit rescue guard reverts on the vault asset, making wANET strictly one-way-in for non-burn paths.

Web4 Phase — ANET Layer 1 Blockchain

A-Network now operates a live ANTS Mainnet that extends the ANTS-first Web2 ledger into an on-chain settlement environment. The ANTS Mainnet chain bootstraps genesis from the Web2 ledger, synchronizes activated balances into Layer 1 state, and opens wallet-to-wallet settlement windows on a 2-second cadence. A block is produced only when chain work exists, such as a queued transfer or newly synchronized ANTS supply from Web2. The broader production-grade Web4 activation remains a future milestone subject to engineering readiness and security review.

This should not be understood as a token swap. It is a ledger synchronization and chain-genesis model. On the live ANTS Mainnet, wallet state, completed-session history, and activated ANTS balances from the Web2 database are imported into the Layer 1 genesis snapshot and may continue receiving periodic delta settlements while the chain is running. The first 1,000 completed sessions remain the threshold before spendable Layer 1 ANET conversion begins.

The Layer 1 coin model is designed so that spendable network coin begins with miners. There is no founder mining reserve and no owner mining reserve. Users who reach the threshold can convert mined ANTS to Layer 1 ANET and participate in wallet-to-wallet settlement on the chain. The separate Web3 utility token is intended to complement that flow rather than substitute for miner-earned Layer 1 issuance.

Time-Based Proof-of-Work (TPoW)

Traditional Proof-of-Work systems rely on computational expenditure and therefore tend to favor specialized hardware operators. A-Network attempts a different entry rule.

Its Time-Based Proof-of-Work (TPoW) replaces computational expenditure with committed time. In the Web2 phase, the work unit is a verified 6-hour session. In the Live ANTS Mainnet, settlement windows are decoupled from that off-chain work interval and reopen every 2 seconds, while blocks are emitted only when transfers or synchronized ANTS supply exist. Validator eligibility continues to derive from real Web2 session activity.

Phase 5 (Roadmap): Decentralized Mining Proofs — Research Spec

When activated, Phase 5 will enable miners to create cryptographically-signed proofs without relying on centralized server approval. Miners would generate proofs locally using a time-based difficulty challenge, sign them with their secp256k1 private key, and submit them directly to the chain. Any validator could then independently verify these proofs using public cryptography.

Proof-of-Ownership Model

Traditional mining servers act as gatekeepers. Phase 5 replaces this model with cryptographic proof of ownership: a miner proves they control their wallet by signing a proof with their private key. This signature is verifiable by any node without contacting a central authority.

Proof Generation Algorithm

Miners generate proofs by finding a SHA256 hash with a specified number of leading zero bits, without requiring network communication:

Proof Signing and Verification

Once a proof hash is generated, the miner signs it with their secp256k1 private key using a canonical signing format. The signature proves wallet ownership without revealing the key. Validators verify the signature and difficulty independently:

Proof Inclusion in Blocks

Accepted proofs are buffered in-memory and automatically included in the next block. Validators keep proofs for up to 5 minutes; older proofs are discarded. Proofs appear in the block's tpow_proofs array alongside transactions.

Backward Compatibility

Phase 5 is fully backward compatible. The server-approved mining endpoint (POST /mining/complete) remains fully functional. Miners choose which model to use: decentralized proofs or server approval. This dual-mode design ensures no disruption to existing mining operations.

Security Model

Supply Model Unchanged

Phase 5 does not modify the issuance schedule or supply cap. The total supply remains 21,000,000 ANET (hard-coded, immutable). Phase 5 only changes who approves proofs (community validators instead of a server); it does not change how much is issued.

Block Structure on ANET Layer 1

On the live ANTS Mainnet, each block represents a settlement event rather than a 6-hour mining window. Validator eligibility is still derived from completed Web2 mining participation, while wallet-to-wallet transfers settle inside short 2-second windows. If no transfer and no newly synchronized Web2 supply arrives in a window, no block is emitted. The block contains:

Transaction Fees — Paid in Ants

After the max supply of 21,000,000 ANET is reached, no new ANET is created. The long-term network transitions from a block-reward model to a fee-only model. The live ANTS Mainnet already exercises the settlement side of this design by opening 2-second transfer windows, emitting event-driven settlement blocks, tracking validator sets, and accounting for transaction fees in Ants.

In the application dashboard, ANET supply and ANTS supply can both be shown side by side. This gives users a clear view of whole-token economics and smallest-unit accounting at the same time.

Web2 → Web4 Migration Specification

The migration from the Web2 PostgreSQL ledger to the Web4 Layer 1 blockchain is the most critical operation in A-Network's history. It must be transparent, verifiable, and zero-loss. Every wallet identity, migration wallet, ANTS balance, claimed ANET total, and session count must be preserved exactly.

Ledger Re-Organization — Last Miner First

The genesis state of the Web4 chain can be populated from the Web2 database using a recent-activity-first synchronization order. This favors the latest verified state while minimizing downtime for miners who remain active near migration.

ANET Core — Web5 Layer

ANET Core is the long-term Web5 layer of the A-Network design. If Web4 provides chain settlement, ANET Core is intended to provide the identity, governance, and application layer built on top of that settlement base.

In this document, ANET Core is treated as a protocol direction rather than a completed product. Its purpose is to extend participation history into identity, governance, and application access.

Core Features

AI Integration Layer

ANET Core also contemplates a protocol-level AI layer that would enable:

• Personal AI agents — owned by the user, not a corporation. AI models run on the user's data without exporting it to centralized servers.
• Federated learning — AI models improve from participant contributions without centralizing training data.
• On-chain AI inference market — Participants can offer AI compute services and earn Ants for processing inference requests.
• ANET Support Bot — An initial AI assistant built on the ANET Core identity layer, accessible to all miners for ecosystem guidance.

Ant Code Colony System — Mining Gateway And Colony Coordination

A-Network includes a single-level colony system that acts as an entry and coordination structure. The live backend does not implement pyramid rewards, commissions, session credits, or multi-level returns. Ant Codes link colony membership, miner identity, and community structure only.

The purpose of this design is to keep growth metrics separate from issuance. Colony membership is intended to represent active miners and contributors rather than passive spectators. Colony Points (CP) are participation metrics, not monetary claims. The system records who activated whom, but the ledger depends on each participant's own verified session history.

Security Model

Authentication Architecture

The authentication model combines bearer-token access, device-aware checks, and OTP-based challenge flows for elevated-risk actions.

• JWT Tokens: All protected API endpoints require Bearer token authentication. Tokens are issued after password or OTP verification, signed with a 7-day lifetime, and enforced with explicit expiration validation.
• Session Binding: Every issued token is bound to session_nonce, device_id, and device_fingerprint. Middleware rejects copied or stale tokens when nonce or device context no longer matches stored session state.
• Email OTP (Registration): Account activation requires OTP verification during registration.
• Smart Login OTP: On login, the server evaluates device and IP risk. If risk is detected, a 6-digit email OTP is required through POST /auth/verify-login-otp.
• Trusted Device Management: Devices become trusted after successful OTP verification. Subsequent logins from the same device may bypass OTP unless the IP context changes. OTP attempts are capped.
• One-Time Account Restore: If an account is in the scheduled-deletion state, the owner can request an email OTP through POST /auth/account-restore/request and confirm it through POST /auth/account-restore/confirm. This recovery path is intentionally single-use.
• Rate Limiting: Global baseline 100 requests per 15 minutes per IP, with additional route-specific throttles for auth/mining actions.
• Protected Session Status: Mining status endpoints require authentication and user-ownership checks; cross-account status queries are denied.
• IP Logging: Last IP recorded per user for anomaly detection (not persisted in history, only current).
• Multilingual Responses: API error and success messages are localized to the user's preferred_language. English (en) and Filipino (tl) are the launch locales.
• Rejected-Token Audit Trail: Failed token validations are logged as auth_token_rejected events with device and IP context for forensic review.

Database Security

The database security model emphasizes hashed secrets, encrypted recovery material, constrained admin access, and parameterized queries.

• Passwords stored as bcrypt hashes (minimum 10 rounds) — plaintext never stored.
• Wallet identity is generated and linked at account level with server-validated uniqueness constraints.
• Wallet PIN values are stored only as bcrypt hashes; plaintext PINs are never stored.
• Seed phrase vault data is stored encrypted at rest using encrypted seed, IV, and authentication tag fields; legacy plaintext seed values are migrated on-demand and then removed.
• Seed reveal requires both the wallet PIN and a time-limited email OTP, with retry caps enforced server-side.
• Seed phrase should still be stored offline by the account owner after initial backup; server-assisted recovery is a continuity control, not a substitute for self-custody discipline.
• PostgreSQL with parameterized queries throughout — SQL injection surface is zero.
• Admin endpoints are controlled by explicit environment flags and administrative key validation; production disables bootstrap/test admin flows by default.
• Ban operations are auditable: every ban records the admin who executed it, the timestamp, and the reason. Unban operations clear the record entirely.

Execution Surface Policy

A-Network separates information access from execution authority. Public web clients are intended for transparency and discovery, while authenticated mobile wallet flows are required for state-changing operations.

• Web (public): pool visibility, pricing, quote inspection, and receipt export.
• Mobile wallet (authenticated): swap execution, transfer, and cashout operations after 1,000-session eligibility.
• Policy objective: enforce miner-first onboarding, preserve anti-abuse controls, and avoid unauthenticated execution paths.

Ledger Integrity

Ledger integrity depends on precision-safe storage, transactional mutation, and row-level locking around reward-sensitive operations.

• DECIMAL(20,8) balance type for legacy ant_balance; a parallel ants_balance field stored as BIGINT is used for precision-safe integer arithmetic.
• All session claim operations are wrapped in a database transaction with row-level locking (SELECT ... FOR UPDATE) to prevent concurrent double-credit of ANTS from parallel API calls.
• Backward-compatible ledger repair: on login and migration, ants_balance is set to GREATEST(existing, sessions × 4888) — never reduced, never overwritten unsafely.
• Database-level triggers ensure updated_at is always accurate.
• Cascade delete protections on mining session foreign keys.
• All balance changes are atomic SQL transactions — partial credit is impossible.

Session Lifecycle

The session model also includes explicit timing rules for claim windows, notification handling, and dormant-account cleanup.

• Session End Time: Every session claim sets session_end_time = NOW() + 6h for the next session window, enabling exact grace-period enforcement.
• Grace Period: 2-hour grace window after the 6h session window closes. Claims received between 6h and 8h are accepted. Claims after 8h are flagged as missed sessions.
• Notification Worker: A 60-second server interval worker polls for users whose session_end_time ≤ NOW() and notification_sent = FALSE, triggering completion processing and dashboard failsafe updates even if the client missed the local reminder.
• Dormancy Cleanup: A background cleanup service may soft-delete accounts that have never claimed any ANET and have zero completed session history, after 90+ days of inactivity. This only affects genuinely empty/abandoned accounts — accounts with any claimed ANET balance or any session history are never affected. Users receive an in-app notification prior to any dormancy action, and any ANTS returned to the ecosystem ledger come only from accounts with zero recorded earnings.

Roadmap

Official Links

Legal Disclaimer

Full legal documents: Privacy Policy · Terms of Service · Account Deletion