Payments architecture
Escrow: commitment without transfer
When a tenant creates a deployment, they fund an escrow account (x/escrow). The balance is provably committed — providers can verify it exists before serving a lease — but provably not yet transferred: it moves only under settlement rules, never at a counterparty's discretion.
This single mechanism removes both directions of payment risk. The provider is not extending credit to a stranger, and the tenant is not prepaying a stranger. If escrow runs dry, leases close for non-payment; if the deployment closes with balance remaining, it returns to the tenant.
Payments architecture
The metering pipeline
On the provider side, a usage meter collects per-workload resource metrics. A scheduled collector runs hourly: collect metrics, process them into usage records, run anomaly detection, and submit signed batches to the chain. Batches carry the provider's signature — the meter's output is attributable and non-repudiable.
The settlement pipeline defaults are conservative and configurable: one-hour settlement intervals, batches of ten records, three retry attempts, and a reconciliation pass every six hours that cross-checks chain-reported usage against platform metrics with a configurable discrepancy threshold.
Payments architecture
The 24-hour dispute window
No usage record settles immediately. Each sits in a 24-hour window during which either party can dispute or correct it. Anomaly detection has usually flagged outliers before submission, so the window is a backstop — but it is a real one, and disputed records escalate through support intake (x/support) and, where misconduct is alleged, fraud handling (x/fraud).
Payments architecture
Settlement and payout
After the window closes, the settlement module converts validated records into line items priced by lease terms and draws them down from escrow. The provider receives the agreed settlement amount: VirtEngine applies no protocol take or marketplace commission. Validator transaction fees apply to chain messages and are designed to be approximately 90% lower than standard network transaction fees. The provider's revenue arrives as settled chain state, with a complete audit trail from meter to payment.
Payments architecture
What this replaces
In conventional cloud billing, the seller runs the meter, prices the usage, issues the invoice, and adjudicates disputes — a full conflict of interest stack. VirtEngine distributes those roles: the provider meters but signs, the protocol prices and settles, both parties can dispute, and consensus adjudicates by rule. It is billing designed for counterparties who have never met.