Mint your own reward currency
POST /rewards/program — one call mints your points as an on-chain ledger on Sui. Name it, set the earn rules, get the ledger id back. Measured at ~7 seconds on testnet. No vendor onboarding, no points platform contract.
Rewards
Points that are real money.
Mint your own reward currency on Sui in one call. Customers — human or AI agent — earn automatically when they pay, refer, or sign up, and the balance lives in their wallet, not in a vendor's database. Deterministic rules. Public receipts.
one call to mint · ~7s on testnet, measured · over-redeem refused on-chain
pay.one.ie · rewards API
POST /rewards/program
→ { ledgerId: "0xe734…6716" }# your reward currency, minted on Sui
POST /rewards/earn
→ { issued: 10, balance: 0 → 10 }# points land in the holder's wallet
GET /rewards/balance
→ { balance: 10 }# public read — anyone can verify
POST /rewards/redeem (over balance)
→ 409 refused on-chain# the ledger says no, not your support team
1
API call to mint your reward currency
409
The answer an over-redeem gets — enforced by the contract
0
Points a spoofed referral link earned in our production test
6/6
Acceptance legs green against production, receipts on-chain
"Show me the incentive and I will show you the outcome."
On-chain proof
Don't trust this page. Query the chain.
Every loyalty vendor shows you a dashboard. We show you the ledger. These are live objects on Sui testnet — open them and read them yourself, without asking our permission.
The house ledger · live
Open on Suiscan
ONE's own rewards program — a CreditLedger minted 2026-07-06, earning on real paid claims.
0xe734446d09d5d74cd6cac567d1fcda225272bacb4ab64999041a113ae3fc6716 A real earn
95XMfhRd973bsEfm9SHe34RPqgM9sniSVfacKzgm87o Balance 0 → 10 against a named rule. One transaction, points in the holder's wallet.
The promise, settled
0xa53717aab119ce6bbbd720f4ade7d3640c918d766be8c079426d14f85165c5e0 We promised this product in an on-chain contract, built it, and the acceptance test settled it kept — state 3, final. The feature's own receipt.
Verified 2026-07-06 against pay.one.ie. The lifecycle test's own log line: “bound referrer earned 0 → 100; spoofed ref stayed at 0.”
Mint, earn, redeem, verify
Four operations. The ledger enforces the rules, so you don't have to.
1
Mint
One authenticated call creates your program: a name, a symbol, and your earn rules. The response is your on-chain ledger id. That ledger is your reward currency — yours, not a row in our database.
POST /rewards/program → { ledgerId }
2
Earn
Fire an earn against a named rule when a customer pays, signs up, or refers. The points land on-chain in their wallet in one transaction. Agents earn through the same call.
POST /rewards/earn → { issued, balance, txDigest }
3
Redeem
The holder spends points against your offers. An over-redeem aborts inside the Move contract and surfaces as a 409 — refused by the ledger itself, not by a policy your support team has to defend.
POST /rewards/redeem → 200, or 409 on over-redeem
4
Verify
Every issue and redeem is a public transaction. Your customers can check their balance against the chain; your finance team can audit the liability without asking a vendor for an export.
GET /rewards/balance — public read, on-chain truth
What the rewards rail gives you
A loyalty program where trust is a query, not a promise.
Balances your customers own
Points live on-chain against the holder's wallet — not as a liability row in a SaaS database. Anyone can read a balance. Nobody can quietly edit one. GET /rewards/balance is public because the chain already is.
Deterministic earn rules
A rule is { event, points }. A signup, a paid claim, a referral — the rule matches or it doesn't. No model in the loop, no scoring black box. The same event always pays the same points. Your rewards budget cannot hallucinate.
Humans and agents, one rail
An AI agent that refers a customer earns through the identical calls a human does. Affiliate networks assume bank accounts and tax forms; a wallet-native earn rule assumes neither. Reward whichever kind of actor did the work.
Referrals that cannot be spoofed
The referrer is bound once, at signup, as a weighted path in the substrate. Payout resolution reads that path — never a ?ref= parameter on the claim. A forged referral link at payment time earns exactly nothing. We tested it in production; it earned nothing.
We run it on ourselves
ONE's house program pays points on real paid claims through pay.one.ie — same endpoints, same ledger contract, same rules we sell. The house ledger is public. Query it whenever you like.
The refusals are the product
Defined by what it refuses
Any points platform can say yes. Trust comes from the no — and every one of these is enforced by code or contract, not by a policy document.
- 409 — the Move call aborts
Redeem more than the balance
spend_credits_checked refuses inside the contract. Not a policy your support team defends; physics the ledger enforces.
- 401 · unset → 503
Issue points without the issuer secret
Writes are fail-closed. No secret configured means no earns at all — never a silent default.
- Ignored — earns nothing
Spoof a referrer with ?ref= at payment time
The referrer was bound once, at signup, as a weighted path. Payment-time parameters are never consulted.
- Closed loop — no transfer in v1
Transfer points between wallets
Points earn and redeem inside your program only, keeping the regulatory shape loyalty already has. The dial exists; it ships shut.
- Deduped by claim digest
Earn twice on a replayed payment
A retried or replayed claim never double-pays — one payment, one earn, exactly once.
- Same input, same output
Mint the same event into different points
Rules are pure conditions: { event, points }. No model, no scoring, no drift between two identical customers.
Against the points platforms and the punch card
| Feature | ONE Rewards | Points SaaS | Spreadsheet / punch card |
|---|---|---|---|
| Customer can verify their balance independently | |||
| Points survive the vendor (open ledger, no lock-in) | |||
| AI agents can earn on the same rail as humans | |||
| Referral attribution immune to link spoofing | |||
| Over-redeem refused by the ledger, not by policy |
Rewards questions
Your customers already have wallets. Give them a reason to come back.
Mint your reward currency, set the rules once, and let every paid claim, signup, and referral pay out deterministically — to humans and agents alike.
closed-loop v1 · no custody, no points database · receipts on a public chain