Lifecycle invariants
Each financial operation moves through a controlled lifecycle. Within the runtime, state transitions are deterministic: the same inputs and recorded state lead to the same next state.
Trust · Financial Integrity
Integrity means knowing what happened before acting again.
Financial state is only trustworthy if the system can tell a failed attempt from an unknown one, record value movement in one authoritative place, and notice when the outside world disagrees.
Problem
The rails are not deterministic. The system on top has to be careful.
Providers time out, answer late, change their answer, or settle differently from what they reported. A system that treats every response at face value will eventually retry a payment that already went through, or show a balance the provider does not recognise.
- A timeout is treated as a failure and the payout is sent again.
- A duplicate webhook credits a wallet twice.
- A balance is updated directly and no longer matches the events behind it.
- Settlement differs from what was expected and nobody notices for a week.
How the runtime handles it
Six properties the platform is built around.
Idempotent execution
Retries and duplicate requests are designed to collapse into one recorded outcome inside the runtime, so a repeated request does not create a second economic intent.
Ledger authority
Completed operations produce ledger entries. Balances derive from those entries, so the ledger is the authoritative internal record of financial state.
Finality awareness
Where automatic pay-in failover exists (payment requests such as Bre-B QR and key), it only retries before anything has been collected, and a provider rejection or an unknown outcome stops it. Payout failover is in development.
Reconciliation
Provider-reported outcomes are compared with internal ledger state. Divergence is detected and surfaced rather than absorbed.
Execution boundaries
Workflows decide what should happen. Financial execution is the only path that moves value. A workflow step cannot change a balance on its own.
In practice
Reconciliation detects divergence. Resolve governs what happens next.
- Economic intent
- Execution Idempotent, lifecycle-governed
- Provider attempt External, not deterministic
- Ledger entry Authoritative internal state
- Reconciliation Internal state vs. provider reality
- Verified outcome States agree
- Resolve case Mismatch or unknown finality
What we do not claim
No exactly-once promises across systems we do not control.
Orangepill does not claim that every operation completes exactly once across external providers, or that settlement is guaranteed. External rails can behave ambiguously, and no runtime can change that. What the platform does is make ambiguity explicit, keep authoritative state in the ledger, and require reconciliation before remediation.
Where does your financial state drift today?
Bring one flow that needs manual reconciliation. We will map where the runtime would detect and govern the divergence.