Reaching A Network's session ledger and its on-chain ANET balance

What an A Network account actually holds

Every six hours of validated elapsed time, A Network writes one completed mining session to a per-account counter; the same account also carries an ANTS balance and, separately, a BEP-20 ANET balance on BNB Smart Chain. Those two numbers are not the same thing and an integration that conflates them will mislead whoever consumes it. The whitepaper is explicit that holding the Web3 token does not issue mined Layer 1 ANET, and that mined ANTS only convert to spendable ANET after a participant clears 1,000 verified sessions.

So there are two stores worth reaching. One is the server-side ledger behind the login — sessions, heartbeat checks, ANTS, colony membership, wallet identity — gated by a 7-day JWT and a six-digit email OTP that fires on an unrecognised device or IP, per the whitepaper's authentication section. The other is public chain state: the ANET contract on BNB Smart Chain, readable by anyone with an RPC endpoint. The route we would take pairs an authorized read of the first with a permissionless read of the second, reconciled into one record.

Data surfaces inside A Network

Bottom line: the valuable, hard part is the consented account ledger, because the session and ANTS state lives only there. The on-chain piece is easy and durable but narrow. A useful integration carries both, kept apart.

How we reach the ANTS ledger and the ANET balance

Authorized protocol analysis of the app interface

The mobile app talks to A Network's backend over an authenticated channel: email-credential login, a JWT bearer token with a 7-day lifetime, a session nonce bound to a device fingerprint, and a six-digit email OTP that triggers when the device or IP is not recognised, all described in the whitepaper. Working with the account holder, we map the request and response shapes for session start, heartbeat, session completion, ANTS balance, colony and wallet status. Reachable: the full per-account off-chain ledger. Effort is moderate. Durability is tied to the app build, which is why we re-validate against the live app whenever a new phase ships. Access is arranged with the account holder during onboarding; the OTP and token are obtained with them, and the integration runs on the trusted-device path so it does not keep re-prompting.

Public reads on BNB Smart Chain

The ANET token is a BEP-20 contract on BNB Smart Chain (chain 56). Balance, transfer history and supply are readable through any BNB Smart Chain RPC or block explorer against the contract address the whitepaper publishes. No consent is required because this is public chain state. Effort is low and durability is high; the contract is fixed-supply with no mint path per the whitepaper, so the read surface is stable.

Public Layer 1 explorer

A Network runs a Layer 1 private mainnet with its own block explorer. Synchronised supply and transfer evidence is visible there and is useful as a cross-check on settlement events. The mainnet is still private and the roadmap is moving, so we treat this as corroboration rather than a primary feed.

What we would actually do: build the consented interface read as the core, because the session and ANTS history exists nowhere else, and bolt the on-chain BNB Smart Chain read alongside it as a stable second source. The explorer read is a verification layer, not the spine. A team that only needs the token balance can take the on-chain route on its own — it is genuinely smaller work.

The auth and session calls, sketched

Illustrative only; exact field names and headers are confirmed against the live app during the build. The shape below reflects the JWT plus smart-OTP flow and the six-hour session unit the whitepaper describes.

# 1. Authenticate (email credential -> JWT, 7-day lifetime)
POST /auth/login
  body: { email, password }
  -> 200 { access_token, device_trusted: false }
  -> 401 OTP_REQUIRED  (unrecognised device or IP)

# 2. Smart OTP, only on a new device/IP
POST /auth/otp/verify
  body: { email, otp_code }            # 6 digits, ~5 min expiry
  -> 200 { access_token, device_trusted: true }

# 3. Read the per-account mining ledger
GET /mining/sessions?limit=50
  headers: Authorization: Bearer 
  -> 200 {
       completed_sessions: 1184,        # drives the 1,000-session gate
       active: { started_at, heartbeats: 2, max_gap_min: 120 },
       ants_balance: "734120000000",    # ANTS, 1 ANET = 1e8 ANTS
       colony: { direct_members, reached_1000 }
     }

# 4. Reconcile with public on-chain balance (no consent needed)
JSON-RPC eth_call -> ANET.balanceOf(account_wallet)
  network: BNB Smart Chain (chain 56)   # BEP-20, 8 decimals per whitepaper
  -> on_chain_anet  (independent of mined ANTS)

# Error handling worth wiring:
#  - 401 mid-sync  -> refresh via trusted-device token, do not re-OTP blindly
#  - heartbeat gap  -> session may be voided server-side; mark, do not retry-spam
#  - RPC rate cap   -> back off; on-chain state is not time-critical
        

What lands at the end of the build

For A Network specifically the package is:

• An OpenAPI specification covering the consented endpoints — login, OTP verify, session list, ANTS balance, colony, wallet status — with the auth scheme documented.
• A protocol and auth-flow report: the JWT lifetime, the smart-OTP trigger conditions, the device-fingerprint and trusted-device behaviour, and how a long-running sync stays inside it.
• Runnable source for the key reads in Python and Node.js, including the BNB Smart Chain balanceOf call so the on-chain ANET balance comes back next to the off-chain ANTS figure.
• Automated tests, including the OTP-required branch and a heartbeat-void case, so a broken sync is visible early.
• Interface documentation that states plainly which fields are server-side ledger and which are public chain, and that mined ANTS is not on-chain ANET.
• Data-retention and consent guidance written against the privacy regime below.

A normalized shape for the two ledgers

One reconciled record, with the off-chain and on-chain sides kept distinct on purpose:

{
  "account_ref": "acct_*",
  "mining": {
    "completed_sessions": 1184,
    "eligible_for_conversion": true,      // sessions >= 1000
    "ants_balance": "734120000000",       // server-side ledger, ANTS
    "active_session": { "heartbeats": 2, "void_risk": false }
  },
  "onchain": {
    "network": "bnb-smart-chain",
    "standard": "BEP-20",
    "anet_balance": "0",                  // independent of mined ANTS
    "source": "contract read, no consent"
  },
  "reconciliation_note": "ants_balance and anet_balance are NOT the same asset"
}
        

Where teams put this data to work

• A portfolio tool that wants a participant's true mined position shows ANTS and completed sessions from the consented ledger, and lists on-chain ANET separately so the user is not double-counted.
• An analytics product tracking participation reads completed-session counts and colony membership over time, without ever needing wallet secrets.
• A treasury or accounting workflow tracks only the BEP-20 ANET on BNB Smart Chain, taking the narrow public-read route with no account access at all.
• A compliance review reconciles the Layer 1 explorer's synchronised supply against the off-chain ANTS ledger to evidence that conversion respected the 1,000-session gate.

California privacy law and consent scope

A Network LLC is a California entity per its whitepaper, so the account data sits under the California Consumer Privacy Act and its CPRA amendments, enforced by the California Privacy Protection Agency. The agency's amended regulations took effect on 1 January 2026 and reach access, deletion and opt-out handling. The app's own privacy policy enumerates what it collects — email and login credentials, OTP metadata, device, IP and session identifiers, mining activity including session timing and ANTS balances, wallet addresses and encrypted seed-vault metadata — and notably does not itself cite CCPA or GDPR, which is a gap we flag rather than paper over.

Consent is scoped to the account holder. We obtain the JWT and any OTP with them, pull only the fields the use case needs, and never touch the wallet PIN or seed material. Consent and access events are logged. The privacy policy describes a scheduled-deletion path with a one-time email-OTP restore window; we document that in the handover so a downstream system honours a deletion request correctly. NDAs are in place where the engagement calls for them.

Things this specific build has to get right

Two account numbers, one mistake to avoid. The ANTS figure is a Web2 ledger value that only becomes spendable ANET after 1,000 verified sessions; the BEP-20 ANET on BNB Smart Chain moves on its own. We model them as separate reconciled fields and label them in the schema, because the easiest failure here is a consumer treating on-chain ANET as the mined balance.

The session engine scores behaviour. Server-side validation enforces a heartbeat ceiling near 120 minutes and flags patterns such as near-identical session start times. We pace the consented read to the six-hour session boundary and route it through the trusted-device path, so the sync's request shape does not look like the automated patterns the abuse scorer reacts to.

The token lifetime is short and the OTP is conditional. The JWT runs roughly seven days and the smart-OTP fires on a new device or IP. We set the sync up against the trusted-device path with a refresh routine arranged with the account holder, so a consented session does not silently expire mid-run.

The app is mid-roadmap. It is Flutter-based and phases are still landing — validator activation and conversions among them. We schedule a re-check against the live build each time a new phase ships, so a changed payload is caught before it breaks parsing rather than after.

What the app screens show

How this mapping was put together

Checked in May 2026 against the operator's own published material and the relevant California regulator. The A-Network whitepaper supplied the token, session, authentication and lifecycle detail; the app's privacy policy supplied the collected-data categories and the deletion path; the California Privacy Protection Agency's regulations page confirmed the 1 January 2026 effective date. Concrete constants here — the contract details, session limits, entity registration — are stated as the operator's own published figures, not independently re-verified.

Citations: A-Network whitepaper, A-Network privacy policy, California Privacy Protection Agency regulations.

Mapped by the OpenBanking Studio integration desk, May 2026.

Other apps in the same mining-and-token space

Same category, useful when a unified integration spans more than one of them. Plain ecosystem context, no ranking.

• Pi Network — daily tap-to-mine on a Stellar-based consensus; holds per-account mining balances and a referral graph behind login.
• Bee Network — 24-hour tap mining with referral teams; server-side balance and team records per account.
• StormGain — cloud Bitcoin mining with periodic manual activation, plus an integrated wallet and trading balances.
• CryptoTab Browser — browser-based mining crediting a per-account balance with a withdrawal ledger.
• MinerGate Mobile Miner — mobile mining with per-account hashrate and payout history.
• NiceHash — hash-power marketplace with account balances, payout addresses and order records.
• ECOS — cloud-mining contracts with account dashboards, contract terms and payout records.
• Binance Pool — pool mining tied to an exchange account with earnings and sub-account records.

Questions integrators ask about A Network

Can the mined ANTS balance be separated from the on-chain ANET token in what you deliver?

Yes. They are two different ledgers. ANTS and completed-session counts live in the server-side Web2 ledger behind the account and only become spendable ANET after 1,000 verified sessions, while the BEP-20 ANET on BNB Smart Chain moves on its own and does not represent mined balance. We model them as separate, reconciled fields so neither is mistaken for the other.

Does reading the session history risk tripping A Network's anti-fraud scoring?

It can if a job hammers the endpoints. The app validates sessions server-side with a heartbeat ceiling around 120 minutes and flags patterns like near-identical session start times. We pace reads to the six-hour session boundary and run the consented sync through the trusted-device path, so the integration's request shape does not resemble the patterns the abuse scorer reacts to.

Which California privacy obligations apply to the account data we would receive?

A Network LLC is registered in California per its whitepaper, so CCPA and CPRA apply, enforced by the California Privacy Protection Agency, whose amended regulations took effect on 1 January 2026. We arrange access with the account holder, keep the pull to the fields the use case needs, log consent, and document the deletion and one-time restore path the app's own policy describes.

If only the BEP-20 ANET balance matters and not the mining ledger, is that a narrower build?

It is. An on-chain read of the ANET contract on BNB Smart Chain — balance, transfers, supply — needs no account consent and is a smaller, durable piece of work than the consented Web2 session ledger. We often deliver that as a standalone endpoint and add the off-chain ledger later if it is needed.