Cannot transact with Telos Mainnet

[firmwareguru]

Since Dec 11, 2025, no transactions are seen on airv11.meas account. Last seen trx: https://explorer.telos.net/transaction/1ba0fb036fe563e759e6e7af53db39cb7be5e3a9bba3804bc021be70a3c279b1

Further interaction with Telos Mainnet RPC endpoint "mainnet.telos.net" shows "400" error on RPC calls that require JSON payloads. Telos Testnet "testnet.telos.net" has no such problem, nor other Telos Mainnet endpoints, e.g. "telos.greymass.com"

[firmwareguru]

Switching to telos.greymass.com solves the trx submission issue. mainnet.telos.net remains viable for TAPOS data acquisition.

Check it out live: https://www.measurement.earth/

[firmwareguru]

Updates:

• eosnation is no longer running an API access point for neither Telos Mainnet nor Telos Testnet
• greymass no longer accepts 'http' URLs, requiring the 'https' form.

As a result, the sensor data streams are not being recorded on chain for either network (greymass and eosnation were the two APs defined in the application).

[firmwareguru]

Access Point pool changes:

• Remove defunct eosnation.io endpoints (testnet + mainnet)
• Fix greymass.com endpoints to use https:// instead of http://
• Add caleos.io endpoints (testnet.telos.caleos.io, telos.caleos.io)
• Add eosphere.io endpoints (telos-testnet.eosphere.io, telos.eosphere.io)
• Add eosrio.io endpoints (testnet.telos.eosrio.io, telos.eosrio.io)
• Add cryptolions.io endpoints (telos-testnet.cryptolions.io, telos.cryptolions.io)
• Add telosunlimited endpoints (api.testnet.telosunlimited.com, api.telosunlimited.com)
• Add valid flag to each AP pool entry (true/false based on TAPOS health check)
• Add pool_index to each chain state for round-robin TAPOS health checks

TAPOS manager:

• Replace random AP selection with round-robin cycling (pool_index advances each check)
• Each AP independently marked valid/invalid based on TAPOS acquisition result
• Use https.get or http.get based on api.method field
• Fast retry (10-30s) only when ALL APs are invalid; normal 5-10 min window otherwise
• After successful TAPOS acquisition, immediately attempt to flush pending trx queue
• Fix Date().now -> Date.now() bug in TAPOS acquisition timestamp

Transaction dispatch:

• dispatch_trx() now accepts full api object instead of just host string
• Selects https.request or http.request based on api.method; uses port 443 or 80
• Trx removed from queue only on HTTP 2xx success (200 or 202 Accepted)
• On failure, started=false so trx remains queued for retry
• manage_dispatch_queues() randomly selects from valid APs (not always first/greymass)

Unrecoverable error handling:

• Add TRX_UNRECOVERABLE_ERROR_CODES Set
• On non-2xx response, parse body and drop trx immediately if error code matches set
• Retryable errors leave trx in queue with started=false

Per-chain server statistics:

• Add make_chain_stats() and server_stats object keyed by chain name
• Track trx_dropped_total, trx_dropped_unrecoverable, trx_dropped_other per chain
• Track per-error-code hit counts in unrecoverable_errors map
• Propagate chain_key into dispatch queue entries for stats attribution

Dashboard (dashboard/index.html + dashboard/app.js):

• Add Server Statistics card with per-chain drop counters and error code breakdown
• Add Access Point Status card with per-AP valid/invalid badge, version, error counts
• Add Refresh All APs button: triggers immediate parallel check of all APs via GET /api/tapos_refresh
• AP status auto-refreshes every 5s; server stats auto-refreshes every 5s

New API endpoints (dashboard listener port 3000):

• GET /api/ap_status: clean per-AP status summary (no network calls)
• GET /api/tapos_refresh: parallel check of all APs, returns updated ap_status
• GET /api/server_stats: per-chain drop counters and unrecoverable error breakdown"