unTHE USER PATHPrefunded payout
Crypto reserveCapital funded in advance
Sui contractCheck → record → pay
User walletReceipt + crypto
Subject to approval, available liquidity and chain confirmation. No need to wait for that purchase’s yen settlement.
Yen takes its time.
Your next step shouldn’t.
A prefunded crypto buffer separates the user’s payout from the merchant’s settlement schedule. Sui records the payout. Yen replenishes the buffer later.
Sui ledger: devnet prototype SB Payment + conversion: proposed integration
Follow the payment architecture from merchant purchase to yen settlement, treasury replenishment and a verifiable Sui payout.
01 / TWO PATHS, ONE RECONCILED RECORDA purchase now.
A purchase now.
Settlement later.
In the proposed flow, a supported merchant purchase creates a yen receivable. After authoritative payment confirmation and eligibility checks, UnSui authorizes a crypto payout from funds already in its treasury.
THE MONEY CYCLE
TARGET PAYMENT FLOWPay ahead. Settle. Refill. Repeat.
Read clockwise. Arrows connect stages in the lifecycle; yen settlement and crypto payouts use separate rails. Operator capital funds the initial buffer before the first payout.
PROPOSED PAYMENT INTEGRATIONArrows show value movement or authorization—not elapsed time.
- 01 · PAYMENT
Eligible purchase
Customer pays through an approved payment channel.
- 02 · CONFIRMATION
SB Payment record
Verify merchant, order, amount and completed payment status.
- 03 · AUTHORIZATION
UnSui authorizer
Bind the eligible payment to one recipient and payout entitlement.
Payment confirmedTwo independent paths
THE TREASURY PATHReplenishment later
Yen settlementMerchant bank account
ConversionSeparate provider / venue
Crypto reserveReconcile + replenish
Net settled yen is converted through a separately arranged, suitable provider. SBPS is not shown as performing crypto conversion.
Confirmed does not mean settled. A payment result, a merchant receivable, cleared bank cash and available crypto are different balances. Only crypto already available in the pool can fund an immediate on-chain payout. SBPS settlement reference ↗
The proposed crypto-linked use case and the exact payment channel must be accepted by the relevant providers before launch. A merchant ID alone does not authorize cash-out or crypto purchases. A phone reading a Suica balance is not a merchant payment or card debit.
ONE CUSTOMER TRANSACTION
Where the card is charged—and what follows.
- NO DEBIT YET
Read & quote
Read the card for context, choose the payout wallet and show the amount and quote. Reading NFC alone does not charge the card.
- CARD DEBIT HAPPENS HERE
Accept the card payment
The customer approves the purchase at a supported merchant terminal or payment integration. The payment system performs the actual debit.
- SERVER-SIDE VERIFICATION
Verify the completed payment
The backend checks the processor result, merchant, order and amount. A failed or unknown payment does not authorize a payout.
- DUPLICATE-PAYOUT GATE
Consume the entitlement
Bind the verified payment to one payout entitlement. The target contract checks it is unused and within its amount cap; current code checks request IDs and card totals.
- PAYOUT + RECORD
Transfer & issue a receipt
An approved on-chain transaction pays from the crypto buffer and records the receipt atomically. A retry reuses the same claim, not a new card charge.
Two systems, two outcomes. The card debit and crypto transfer are not one atomic transaction. If the payout is delayed or fails after a successful payment, keep the entitlement pending for reconciliation and retry; any payment reversal follows the original payment channel. The current dGen1 NFC reader does not execute the merchant debit.
02 / THE MERCHANT RECORDThe merchant ID identifies us.
The merchant ID identifies us.
The payment record identifies the money.
Our proposed SBPS integration uses the identifiers supplied for the contracted service, with a backend that verifies payment results. The browser cannot authorize payouts by reporting “payment successful.”
ILLUSTRATIVE RECORD · NO LIVE ACCOUNT
Merchant purchase
- merchant_id
- Assigned by SBPS
- service_id
- Contracted service
- Order reference
- UNSUI-ORDER-0042
- Processor reference
- Tracking / transaction ID
- Purchase amount
- ¥1,500
- Payment state
- Verified completion
- Settlement state
- Awaiting bank settlement
Field availability and naming depend on the selected SBPS integration. The sample values are not credentials.
Accept through the right channel
Physical Suica acceptance needs a supported merchant terminal or certified payment integration. The dGen1’s current NFC reader only reads card data. An online Mobile Suica payment flow is a separate integration.
Confirm from an authoritative source
Validate the service-specific server notification and/or processor status query, match the expected merchant and order, and reconcile the amount. Do not trust a redirect page or a screenshot as proof of payment.
Map the payment to an entitlement
Store the unique processor payment reference, amount, destination wallet and quote. Retries must reuse the same entitlement. Partial payouts must never exceed its authorized total.
Crypto payout and processor refund are separate operations. This proposal pays from UnSui’s treasury. It does not describe SBPS issuing a crypto refund. Cancellations and refunds must be reconciled with the original payment flow; an already completed on-chain transfer does not reverse automatically. SBPS payment/refund functions ↗
03 / LIQUIDITY BEFORE SPEED
The buffer buys time.
UnSui prefunds a crypto treasury using operator capital. User payouts reduce it. Bank settlement and later conversion replenish it. Pending yen is tracked separately and never counted as spendable SUI.
TRY THE TREASURY MODELGive the buffer
Give the buffer
a little pressure.
Adjust the opening balance and settlement delay. Watch the payout queue grow when the reserve floor would be breached.
Available crypto in the pool
10-day illustration · SUICrypto available3 SUI reserve floorPayouts queued
Paid over 10 days50 SUI
End-of-day pool4.3 SUI
Waiting for liquidity0 SUI
Illustrative assumptions: ¥10,000 per SUI, 2% combined settlement/conversion cost, one purchase batch per day, and a 3 SUI minimum reserve. Fees reduce replenishment, so an equal gross payout erodes the buffer. This is not a live price, an SBPS fee quote, or an SBPS settlement promise. Whole daily batches wait in order; gas, price movements and payment reversals are excluded.
Size for the gap
Plan for payout demand across the entire settlement-and-conversion window, plus gas, market moves and a safety margin. A bank holiday or delayed conversion can extend that window.
Working buffer ≈ daily crypto demand × lag + reserveStop before empty
The proposed service queues or pauses new authorizations below its reserve threshold. The current Move contract aborts if its SUI pool cannot cover a payout; it does not implement this model’s 3 SUI floor or queue.
Reconcile before refill
Match settled net yen against processor reports, fees and reversals. Record the conversion execution and on-chain deposit. FX changes, fees and losses need capital or an explicit pricing policy.
04 / ONE CLAIM, ONE PAYOUTSui makes the payout
Sui makes the payout
and the record inseparable.
The deployed prototype uses a shared Move ledger. Every successful refund updates the card’s total and sequence, consumes a request ID, creates an immutable receipt and transfers SUI in one transaction.
INPUT
Authorized request
Card commitment
Request ID + recipient
Amount + observed balance
Expected sequence + expiry
CONTRACT GATES
Check every condition
- Authorized operator; not paused
- Request ID not already consumed
- Expected card sequence matches
- Within attested balance + expiry
- Enough SUI in the pool
ATOMIC RESULT
Record + transfer
Advance total and sequence
Link and freeze receipt
Emit refund event
Pay the destination wallet
Any check failsTransaction abortsNo partial payout or partial ledger update. Transaction gas may still be charged.
Prevent replay inside this ledger.
Submitting the same request ID twice cannot pay twice. A stale sequence rejects racing updates. Cumulative refunds cannot exceed the operator-attested balance for that card commitment. These checks do not authenticate the physical card balance.
Consume the payment—not just a request.
Add a unique payment commitment derived from the verified processor reference and merchant context. Enforce its payout cap on-chain so a second request ID cannot redeem the same purchase again. This merchant-payment binding is not in the current contract.
Ethereum is a browser preview only. Production payouts on multiple chains need a shared entitlement authority and reservation/finality handling; two independent “used payment” lists would not prevent the same purchase being claimed on both chains.
Inspect the deployed prototype DEVNET
Move package
0x79671e6551904e82ac6fe908986a0093ce35ceb1e03cfa01402d266fb0744af5Shared treasury & ledger
0xdcd6d129a7ae31977f12fa1720fd1697bea07e7666f1792cdbd56edf0b77848eImmutable example receipt
0x342f19822af931dbd0f3802a579cc7cf24f2def675ba2434ee139fa6949984f3Example payout transaction
6EuqKUAbzYEg2MqpuFCr9ERcjFMezPZoCgnwGdPekffLDeployment recorded on 22 September 2026. These are published test-network records, not live balance readings. Devnet resets can remove them. The publisher retains upgrade and administration capabilities.
05 / TRANSPARENCY WITH A CLEAR BOUNDARYShow what can be proven.
Show what can be proven.
Name what still needs trust.
The contract makes crypto state inspectable. Reconciliation joins it to off-chain payment and bank records. Neither a hash nor a Merkle tree turns an unverified yen claim into verified cash.
The receipt chain
Receipt #1Hash A
Receipt #2Includes Hash A
Receipt #3Includes Hash B
Each receipt commits to the previous receipt’s ID and hash, the current claim, sequence and timestamp. The shared ledger stores the latest head.
The claim commitment
These are the deployed Move contract’s four leaves. The receipt hash covers the full BCS-encoded receipt. The website’s local demo uses a separate illustrative format.
| Record | Where it lives | What it establishes |
|---|---|---|
| SUI pool, transfers and immutable receipts | Sui · publicly inspectable | Crypto funds and the recorded payout history; not the merchant’s bank balance. |
| Card commitment and refund sequence | Sui · publicly inspectable | Pseudonymous continuity within the ledger. It does not prove card ownership or a card debit. |
| Payment status and processor reference | Proposed merchant backend | Verified purchase entitlement, based on authenticated processor data. |
| Yen settlement and conversion execution | Proposed bank / provider reconciliation | What arrived, fees and reversals, and how much crypto was acquired. |
| Raw NFC ID and travel history | Off-chain | Not published in the contract; keyed commitments are pseudonyms, not guaranteed anonymity. |
The contract replaces the payout ledger—not every business record.
SBPS payment references, reconciliation, conversion orders and exception handling still need durable off-chain records. A future audit report could commit reconciliation batches on-chain, but the current prototype does not attest to fiat reserves.
06 / TODAY & THE NEXT STOPA working proof.
A working proof.
A defined path to payments.
Explore it today
- Native FeliCa balance and history reading
- Devnet Move treasury and refund ledger
- Request replay and sequence protection
- Immutable, linked receipts and Merkle commitments
- Standalone browser walkthrough
Connect the merchant rail
- Provider acceptance of this specific use case
- Contracted merchant ID and supported acceptance channel
- Authenticated payment verification and binding
- Bank settlement and conversion reconciliation
- Liquidity policy, reversal handling and security review
Primary sources & implementation notes
Payment details below are provider documentation. The architecture, buffer model and future controls on this page are UnSui’s proposal.