PulseGriddocsLaunch ↗

Roadmap

Where PulseGrid is, and what is next. We list the credibility gaps openly, because for a network that settles real value the honest gaps matter more than the feature list.

Shipped and live on mainnet

  • The full settlement engine on BOT Chain mainnet (chainId 677), settling in canonical USDT, with all four PulseGrid contracts Blockscout-verified.
  • Value-layer SLAs: settlement checks data quality (signed in-range readings), not just liveness.
  • Permissionless keepers: anyone can drive settlement for an equal tip from a dedicated pool, without weakening the guarantee.
  • Gasless devices via a self-hosted, MegaFuel-shaped sponsor relayer (devices spend zero gas).
  • Real-hardware device SDK: an importable Go package plus a standalone binary with an encrypted keystore.
  • An adversarial Foundry suite (81 passing tests) and an internal, AI-assisted review (see Security).

Product: what is next

  • Multi-asset settlement (additional stablecoins via a DEX; the vault is already asset-agnostic).
  • Batched settlement to cut per-interval overhead as the fleet grows.
  • Richer bonding and reputation: risk-priced bonds and a stronger reputation signal.
  • A real anomaly-detection model feeding the advisory layer (kept strictly non-authoritative; it never touches settlement).

Trust and decentralization: the gaps we are closing

These are the items a serious operator or partner should ask about. In rough order of leverage:

  1. External smart-contract audit. The largest outstanding trust item for real-USDT settlement. The contracts have an internal AI-assisted review and an adversarial test suite today; an independent third-party audit is planned, and the report will be published.
  2. Bug bounty. A public program (once the audit lands) so researchers are paid to find issues.
  3. Key custody. Today a single operator key holds the deployer, treasury, relayer, and settler roles. The plan is to move the treasury and contract owner to a multisig and split the hot keys, and to run a second keeper so the permissionless keeper set is demonstrated in practice, not just in code.
  4. Real-hardware pilot. The browser and CLI paths are on-ramps; running one physical device end-to-end is the next credibility step.
  5. Availability model. Because BOT Chain has a gas floor, the streaming fleet runs in short funded windows rather than 24/7. We will either fund sustained operation or publish a clear windowed schedule plus a public status page, so availability is never ambiguous.
  6. Native gasless. BOT Chain advertises an EOA paymaster, but none is live on mainnet or testnet and it does not sponsor blob transactions (logged as BOUNTY_LOG B-008). We run a self-hosted sponsor and will point the device path at a native paymaster the moment one ships. Devices are provably zero-gas either way.
  7. Domain and channels. A custom domain and public community channels (currently the project runs on a vercel.app subdomain with no socials yet).

Nothing above changes the on-chain guarantee: an operator cannot be paid for undelivered or out-of-range data, and the agent cannot stiff an honest operator, because on-chain policy re-derives every settlement.