Venom · how money moves

Three ways to pay, one escrow

Every payment lands in the same escrow contract and is released only when the supplier confirms. The three modes differ in who signs and how often.

The boundary every flow respects

The part that sells never sees a wallet, and the part that pays never sees a trip. The only thing that crosses is an opaque reference, so there is no amount or address in the conversation to tamper with.

Sells: agent + travel program Pays: pay program + rail Knows: conversation, trips, offers, travellers, passports Never sees: wallets, addresses, balances, limits, keys Knows: wallets, limits, intents, escrow, ledger, buyback Never sees: trips, hotels, names, passports intent_ref pi_7Kq2Wm9RfX3d
Sells: agent + travel programKnows: conversation, trips, offers, travellers, passportsNever sees: wallets, addresses, balances, limits, keys
intent_ref pi_7Kq2Wm9RfX3d only
Pays: pay program + railKnows: wallets, limits, intents, escrow, ledger, buybackNever sees: trips, hotels, names, passports
Mode 1

Approve in wallet

The backend pushes a payment request into the wallet session. The person approves it in the wallet; the web app shows waiting for your wallet and moves on by itself when the chain confirms. Used when there is no allowance or a payment is above the caps.

Person phone Web app chat Agent + travel Pay + rail Wallet keys stay here Chain escrow contract “Yes, all four” confirm order VT-7K3Q9D intent_ref pi_7Kq2… only payment request (session push) person taps Approve in the wallet signed transfer 1,817.00 USDT escrowed · 19 confirmations live status: waiting → escrowed → booked
  1. Person→Web app
    “Yes, all four”
  2. Web app→Agent + travel
    confirm order VT-7K3Q9D
  3. Agent + travel→Pay + rail
    intent_ref pi_7Kq2… only
  4. Pay + rail→Wallet
    payment request, pushed into the session
  5. The person taps Approve in the wallet
  6. Wallet→Chain
    signed transfer 1,817.00 USDT
  7. Chain→Pay + rail
    escrowed · 19 confirmations
  8. Pay + rail→Web app
    live status: waiting → escrowed → booked
Mode 2

Delegated allowance

The person grants caps once, in the wallet. The SpendingPolicy contract enforces them, so a breach of our servers can take no more than the wallet allows, and only into the escrow.

Person phone Web app chat Pay + rail Wallet keys stay here SpendingPolicy caps on chain Chain escrow contract Once sets caps: 2,500 / payment · 4,000 / day · escrow only · until 2 Dec approve(SpendingPolicy) · signed once Every purchase within the caps “Yes, all four” · one tap intent_ref pi_7Kq2… pull 1,817.00 to escrow checks per-payment, daily, destination transfer into escrow escrowed → booked, shown live Any time revoke · one transaction
  1. Once
  2. Person→Wallet
    sets caps: 2,500 per payment · 4,000 per day · escrow only · until 2 Dec
  3. Wallet→SpendingPolicy
    approve(SpendingPolicy), signed once
  4. Every purchase within the caps
  5. Person→Web app
    “Yes, all four” · one tap
  6. Web app→Pay + rail
    intent_ref pi_7Kq2…
  7. Pay + rail→SpendingPolicy
    pull 1,817.00 to escrow
  8. The contract checks per-payment, daily and destination
  9. SpendingPolicy→Chain
    transfer into escrow
  10. Chain→Web app
    escrowed → booked, shown live
  11. Any time
  12. Wallet→SpendingPolicy
    revoke · one transaction
Under 150.00Paid silentlyNothing to confirm. The chat says it was paid and why.
150.00 – 2,500.00One tap in the appThe booking confirmation is the payment confirmation. The Dubai trip, 1,817.00, is here.
Above a capFalls back to mode 1Over 2,500.00 per payment or 4,000.00 per day: approve in the wallet.
Mode 3

Pay by transfer

For any wallet or an exchange withdrawal. The person sends the exact amount with the memo before the quote expires; the chain watcher matches the deposit. Nobody's word counts, only the chain's.

Person phone Web app chat Pay + rail Any wallet or exchange Chain watcher rail Deposit address address, amount, memo, QR person sends from any wallet 1,817.00 USDT · memo VNM-4Q7K-2D deposit seen matched on memo + amount → escrowed settling → booked, shown live If nothing matches: no memo, wrong amount, too late held in suspense, flagged to ops refund to the sender after review
  1. Web app→Person
    address, amount, memo, QR
  2. Person→Any wallet or exchange
    sends from there
  3. Any wallet→Deposit address
    1,817.00 USDT · memo VNM-4Q7K-2D
  4. Deposit address→Chain watcher
    deposit seen
  5. Chain watcher→Pay + rail
    matched on memo and amount → escrowed
  6. Pay + rail→Web app
    settling → booked, shown live
  7. If nothing matches: no memo, wrong amount, too late
  8. Held in suspense and flagged to ops
  9. Chain watcher→Any wallet
    refund to the sender after review
Tracking

How a change reaches the person

After payment the trip keeps moving. The status feed and the airline speak only to the travel program; it turns what they say into a timeline entry, and the platform turns that into a notification. Pay and rail hear nothing unless money moves.

Person phone Web app notifications Agent routing Travel program Duffel simulator Status feed simulator FZ 982 delayed 25 min · polled every 5 min airline change webhook item.updated + timeline push + notification choices, each with its cost person picks “keep the new time” answer change capability, through the agent accept airline change
  1. Status feed→Travel
    FZ 982 delayed 25 min · polled every 5 min
  2. Duffel→Travel
    airline change webhook
  3. Travel→Agent
    item.updated with a timeline entry
  4. Agent→Web app
    push and a notification
  5. Web app→Person
    choices, each with its cost
  6. The person picks “keep the new time”
  7. Person→Web app
    answer
  8. Web app→Travel
    change capability, through the agent
  9. Travel→Duffel
    accept airline change

Screens: airline change in chat, the same by hand, flight status states, notifications.

Money for one booking: 100 → 105

The person pays one amount and sees one amount. The fee is 5 % on top of the supplier price, split exactly in half. The split does not depend on the size of the booking: 200 means 210, with 5 to buyback and 5 to revenue.

Person's wallet pays 105.00 Escrow held until the supplier confirms 105 release Supplier cost 100.00 Revenue 2.50 · half the fee Buyback earmark 2.50 · half the fee OTC → USD → Duffel batched top-ups of the prefunded USD balance VENOM on the open market DEX VENOM/USDT, scheduled, slippage cap 1.00 % not confirmed or failed: all 105.00 back, automatically
Person's walletpays 105.00
105
Escrowheld until the supplier confirmsNot confirmed or failed: all 105.00 back, automatically
release
Supplier cost · 100.00→ OTC → USD → Duffel, batched top-ups of the prefunded balance
Revenue · 2.50half the fee
Buyback earmark · 2.50→ VENOM on the open market, scheduled, slippage cap 1.00 %

The same rule on the Dubai booking

Order VT-7K3Q9D, paid in USDT on TRON. Amounts are integers of the asset's smallest unit (6 decimals for USDT); the person sees 1,817.00, the ledger keeps every digit.

Supplier price (flights 780.95 + hotel 949.53, quoted)
1,730.476190USDT TRC20
Service fee, 5 %
86.523810USDT
buys VENOM
43.261905USDT
revenue
43.261905USDT
The person pays
1,817.000000USDT TRC20
fee = round_half_up(1730476190 × 500 / 10000) = 86523810 buyback = fee // 2 = 43261905 revenue = fee − buyback = 43261905 total = 1730476190 + 86523810 = 1817000000

The same function runs in the contracts, the rail and the UI, checked against shared test vectors. If one half of the fee has an odd last unit, it goes to revenue.