StoneReason Proof Center
See what StoneReason can prove — live.
Live capability evidence, real limits, payment qualification and infrastructure state — derived from deployed truth, not from a brochure. Every number on this page is generated from the running system and the release it was qualified at.
18
Live capabilities
Reachable and qualified on this deployment
10
Payment networks
Operational: 9 light + TRON via the Data plane
Proven
TRON USDT
Mainnet, detected and finalized end-to-end
6,614
Tests pass
0 fail across the workspace
BETA READY
Customer readiness
Free Beta; nothing priced, no SLA
bee2cf0
Deployed release
Qualified 2026-09-16
A capability is never a green light. It is one of: live qualified,
live, conditional, beta, not served, or unestablished — and the difference is the
product. SUPPORTED != HEALTHY. NOT_SERVED != FAILED.
Capability explorer
What is supported today, and how far it is proven.
Filter by state or search. The catalogue is the authority and it refuses everything not on it — a profile existing is not a capability being available.
| Product | Network | Capability | State | What it means |
|---|---|---|---|---|
| Access | Arbitrum One | network.status | Live qualified | Network state and the per-network capability truth. |
| Access | Arbitrum One | network.capabilities | Live qualified | Network state and the per-network capability truth. |
| Access | Avalanche C-Chain | network.status | Live qualified | Network state and the per-network capability truth. |
| Access | Avalanche C-Chain | network.capabilities | Live qualified | Network state and the per-network capability truth. |
| Access | Base | network.status | Live qualified | Network state and the per-network capability truth. |
| Access | Base | network.capabilities | Live qualified | Network state and the per-network capability truth. |
| Access | BNB Smart Chain | network.status | Live qualified | Network state and the per-network capability truth. |
| Access | BNB Smart Chain | network.capabilities | Live qualified | Network state and the per-network capability truth. |
| Access | Ethereum | network.status | Live qualified | Network state and the per-network capability truth. |
| Access | Ethereum | network.capabilities | Live qualified | Network state and the per-network capability truth. |
| Access | Polygon PoS | network.status | Live qualified | Network state and the per-network capability truth. |
| Access | Polygon PoS | network.capabilities | Live qualified | Network state and the per-network capability truth. |
| Wallet | Arbitrum One | balance.get | Live qualified | Native and token balances, by contract address. |
| Wallet | Avalanche C-Chain | balance.get | Live qualified | Native and token balances, by contract address. |
| Wallet | Base | balance.get | Live qualified | Native and token balances, by contract address. |
| Wallet | BNB Smart Chain | balance.get | Live qualified | Native and token balances, by contract address. |
| Wallet | Ethereum | balance.get | Live qualified | Native and token balances, by contract address. |
| Wallet | Polygon PoS | balance.get | Live qualified | Native and token balances, by contract address. |
| Verify | Every answer | trust envelope | Live | Trust class, coverage, evidence basis and finality on every read, never a score. |
| Payments | Arbitrum One | payment.watch | Live | Followed by the light path; watch one destination for USDT. |
| Payments | Avalanche C-Chain | payment.watch | Live | Followed by the light path; watch one destination for USDT. |
| Payments | Base | payment.watch | Live | Followed by the light path; watch one destination for USDC. |
| Payments | BNB Smart Chain | payment.watch | Live | Followed by the light path; watch one destination for USDT. |
| Payments | Celo | payment.watch | Live | Followed by the light path; watch one destination for USDT. |
| Payments | Polygon PoS | payment.watch | Live | Followed by the light path; watch one destination for USDT. |
| Payments | Stellar | payment.watch | Live | Followed by the light path; watch one destination for USDC. |
| Payments | TON | payment.watch | Live | Followed by the light path; watch one destination for TON. |
| Payments | XRP Ledger | payment.watch | Live | Followed by the light path; watch one destination for RLUSD. |
| Payments | TRON | USDT detection | Mainnet proven | A USDT-TRC20 transfer above the creation floor, identified by contract, not ticker. |
| Payments | TRON | native finality | Mainnet proven | Finalized on TRON's own solidified head, the chain's condition, not a count. |
| Payments | TRON | Evidence Receipt | Mainnet proven | A receipt that states what it is and is not, gated on the finality standing. |
| Send | TRON | transaction.broadcast | Not served | TRON is payments-only here. XRPC never holds a key in any case. |
| Monitor | Every network | subscribe.heads | Not served | Generic head and payment watches are not on the Beta surface; a watch is refused, not silently dropped. |
| Send | Independence | second provider route | Unestablished | One qualified provider route today; a second independent route needs an operator key. |
Generated from the deployment manifest. Live component state is on the status page; per-network detail is under networks.
Proof detail · TRON USDT payments
USDT (TRC-20) on TRON Mainnet, proven end to end.
A payment was watched, detected, execution-verified, finalized on TRON's own solidified head, reconciled on four axes and issued a receipt — on mainnet, with an id to point at.
8
Blocks examined
Solidified blocks read
453
USDT logs matched
of 455 transfer-topic logs seen
1
Fully validated
block, tx, logIndex, amount, solidified
Examined and matched are kept apart on purpose:
EMPTY_MATCH_SET != ACQUISITION_SUCCESS.
"payment_id": "pay_e4fd7788...",
"lifecycle": "DETECTED -> CONFIRMING -> FINAL",
"native_finality": "SOLIDIFIED",
"protocol_final": true,
"receipt_id": "rcpt_32a6..."Mechanism: Finalized from TRON's own solidified head (walletsolidity/getnowblock), read once per pass. The chain's own condition: a supermajority of the 27 super representatives has built on the block. It is a threshold, not a confirmation count.
What was tested
- Detection — PASS. A matching USDT-TRC20 transfer above the creation floor, identified by contract and Transfer topic, not by ticker.
- Execution verification — PASS. A TRC-20 Transfer event is only emitted by a transfer that executed; a failed execution is refused.
- Native finality — PASS. Finalized on TRON's solidified head, the chain's own condition, not a block count.
- Reconciliation — PASS. Four axes kept apart: amount, finality, observation, timing. Integer base units.
- Webhook — PASS. Signed webhooks for detected / confirming / final / reorged, with retry, dedup and a resumable cursor.
- Evidence Receipt — PASS. A receipt that states what it is and is not, gated on the finality standing.
What was observed
- 8 solidified blocks examined → 455 transfer-topic logs seen, 453 matched the official USDT contract; one occurrence fully validated (block, tx, logIndex, exact amount, receipt SUCCESS, solidified).
- End-to-end, USDT of 3.400976, 4.604443 to a live recipient, the same occurrence upgraded in place.
- Finalized from the solidified head, not a confirmation count.
What is not claimed
- A second independent provider route: free alternates return 403 and need an operator API key, so MULTIPLE_ROUTES != SOURCE_INDEPENDENCE and source independence is UNESTABLISHED.
- XRPC Send / broadcast on TRON: code-complete but TRON is payments-only here, and a live broadcast is not safe to test without a funded signed transaction. XRPC never holds a key.
- Custody, refunds, chargebacks, swaps or bridges: none exists in this build.
Verdict: PARTIAL. Core non-custodial USDT payment product is complete and proven live end-to-end. The remainder is externally gated (a second independent provider route needs an operator API key), so the milestone is PARTIAL, not because anything is broken.
Live payment demo · Simulated
Every standing a payment can take, without moving a coin.
This walks the seven states a StoneReason payment session moves through. It is a simulation — nothing here touches a chain or moves funds. A real mainnet test is initiated by you, from your own wallet; StoneReason never custodies or refunds test funds.
Session open
The obligation is stated: network, asset, amount, destination.
Transfer seen
A matching transfer above the creation floor, so it cannot be a balance already there.
It ran
A TRC-20 Transfer event is only emitted by a transfer that executed.
Not yet settled
Seen, but not final by TRON's own rule. Credit here only if you accept the reorg risk.
Settled
Final on the solidified head: a supermajority of super representatives has built on the block.
Four axes agree
Amount, finality, observation and timing, kept apart and each satisfied.
Receipt
A receipt that says what it is, and what it is not.
The stated amount arrives and finalizes. may_release_goods becomes true only after finality and reconciliation agree.
A smaller amount arrives. The standing is UNDERPAID — a standing, not an error. Goods are not released.
A larger amount arrives. The standing is OVERPAID, kept distinct so you decide what to do, not the system.
The transfer arrives after the deadline. It is still recognized as a distinct late standing for seven days, not silently dropped.
Detected but not yet solidified. Real, but reversible. The receipt says so, and credit here is your risk decision.
The same occurrence is seen twice. It is deduplicated by a deterministic id, so one payment is never counted as two.
Your endpoint did not answer. Delivery is retried up to six times over about half an hour, with a signed, resumable cursor.
Known limitations
The limits are part of the proof.
A trust product that hides what it has not established is not a trust product. These are current, and stated in the same place as the strengths.
- TRON provider independence: UNESTABLISHED. One qualified provider route (TronGrid). A second independent route needs an operator API key, so agreement between sources cannot yet be treated as evidence.
- Source independence (all networks): UNESTABLISHED. This deployment cannot show that two sources it might ask are operated separately; agreement is treated as availability, not corroboration.
- Customer readiness: BETA READY. Free Beta. Nothing is priced, and no availability is promised or measured.
- Offsite disaster recovery: NOT ESTABLISHED. Local backup and restore are proven; an offsite copy is not yet active. Host loss would be data loss.
- Email delivery round-trip: PARTIAL. The mail transport is proven to accept messages; end-to-end inbox delivery is not separately proven. ACCEPTANCE != DELIVERY.