After chain execution
Payment Truth
“The provider returned success” and “the transaction is on the chain” are not the same as “the right amount reached the right place and it is final.” Payment Truth establishes what actually happened to a payment — as distinct axes, each chain’s own settlement condition in its own terms.
The problem
An application that acts on the wrong signal loses money: it credits a deposit that later reorgs, ships goods against a payment that was underpaid, or waits forever on one that already settled. The signals a provider gives you — a 200, a broadcast, a confirmation count — do not answer the question your business is actually asking.
PROVIDER_SUCCESS != CHAIN_FINALITY
What StoneReason does
It answers the payment as separate questions, and keeps them separate:
Occurrence & amount
Did a payment for this obligation occur, and for how much? Underpaid, overpaid and exact are different answers, not one.
Destination & execution
Did it reach the destination you expected, and did the execution succeed on-chain?
Native finality
Is it final by this chain’s own rule — solidified, finalized, validated — not a confirmation count borrowed from another chain?
Timing
Did it arrive inside the window, late, or after it expired? Timing is its own axis, never folded into “paid.”
What StoneReason does not do
No boolean. It never flattens a chain’s settlement condition into true/false. Each axis carries its own standing.
No provider’s word. It reads the chain itself; a provider saying “done” is not the answer.
No invented finality. It reports the finality a chain can
actually give, and says UNESTABLISHED when it cannot yet.
No custody. Establishing truth touches no funds and holds no keys.
Live on this deployment
The truth model and its axes are live. Live
finality observation runs today on the TRON reference rail, proven
on mainnet; broader-network commercial observation is limited on this deployment, and an
axis that cannot yet be established says so rather than guessing. The underlying
multi-chain reads (balances, network status) are live on
6 networks — see Access.
General-purpose verification of arbitrary transactions
(/v1/verify) is not available on this deployment yet.
The four axes, kept apart
Who this is for: payment teams, wallets, exchanges and platforms that must decide whether it is safe to credit, release or settle — and need the reason, not a guess.
Input: a payment session or an observed payment.
Output: the payment’s truth across occurrence, amount,
destination, execution, native finality and timing.