The end ofpull payments.
Merchants propose. You sign intent. Money, receipts, and warranties settle atomically to a stealth address only you control.
Payments weren't designed
for the internet.
Pull payments are a liability
In pull systems — cards, direct debits, tokenized card vaulting — the payer provides a long-lived capability that can be replayed, stolen, or used beyond the intended context. You hand over withdrawal authority and hope for the best.
Fraud, subscription traps, credential compromise.
Users sign what they can't read
Wallets require users to approve transactions described in function selectors, byte arrays, and object IDs. The mapping to user intent is not always clear or verifiable — you authorize actions you cannot reason about.
A usability failure that becomes a security failure.
Payments lose context
Receipts, warranties, invoices, tax metadata, and proof of ownership are generated off-ledger and stored on disconnected systems. Value transfer is recorded — the semantics of the exchange are not.
Your bank statement encodes −$100 but not the verifiable who/what/why.
A protocol designed from
first principles.
Zero-knowledge identity. Push-only payments. Atomic settlement. Three layers that compose into a single, verifiable commerce primitive. The protocol is intentionally deterministic: the same intent and the same on-chain state yield the same execution.
Invisible by design.
Register a human-readable name that resolves to a stealth meta-address. Every payment derives a fresh one-time address only you can detect — no address reuse, no on-chain identity leaks.
- Human-readable names → stealth meta-addresses
- One-time stealth address per payment (ECDH)
- ZK proofs for eligibility — no PII on-chain
- Anti-Sybil: one credential = one name
You approve. Always.
A typed proposal/acceptance model where merchants propose, wallets accept, and on-chain execution is constrained by the signed intent. No one obtains standing withdrawal authority.
- Typed, human-auditable proposals
- Semantic intent binding
- Unilateral revocation / kill switch
- No standing withdrawal authority
All or nothing.
PTB-based execution on Sui where value transfer and commerce artifacts exchange atomically. Payment, receipts, warranties, and compliance data settle together — or nothing moves.
- Sui Programmable Transaction Blocks
- Commerce artifacts as first-class objects
- Deterministic failure modes
- Composable compliance
From pushing money
to broadcasting intent.
Legacy payment networks tightly couple identity, authorization, and settlement. identiPay breaks this monolith with a Universal Intent Object that is rail-agnostic by design — the same signed intent can settle on any rail.
Native Sui Settlement
USDC-first
The signed Universal Intent Object is wrapped into a Programmable Transaction Block and executed on Sui. USDC transfer and commerce artifact issuance occur in the same state transition — strict cryptographic atomicity with deterministic reconciliation keyed by intent hash.
- Coin<USDC> → ReceiptObject in one PTB
- Full cryptographic atomicity
- Deterministic reconciliation
- No third-party solvers required
Solver Network
Cross-rail fulfillment
A decentralized network of Solvers fulfills signed intents even when payer funds live elsewhere. The payer signs an intent with clear limits — amount, expiry, recipient, nonce. A Solver fronts on the merchant’s preferred rail immediately, then settles back by claiming payer-authorized funds on the external rail.
- Rail-agnostic intent fulfillment
- Economic atomicity via solver fronting
- Merchant sees one integration, one asset
- Solver absorbs cross-rail latency
// Universal Intent Object (UIO){"@context": "did:identipay","zk_proof": "Groth16(age>18 ∧ EU)","terms": "50 EUR → Merchant DID","deliverable": "Warranty #123","stealth_addr": "0x7a2f...e4b1","rail": "agnostic"}Strict cryptographic atomicity is guaranteed when both legs exist on the same ledger. When the protocol abstracts across asynchronous rails, Solvers provide economic atomicity — fronting value instantly and absorbing cross-rail latency for a marginal spread.
One scan.
Verified before you sign.
Commercial proposals are too large for QR codes. identiPay uses a federated URI scheme as a routing pointer — resolved over HTTPS and verified against an on-chain Trust Registry before any intent is signed.
Scan
Customer scans a QR code or taps NFC at checkout. The code encodes a compact URI pointer — not the full proposal.
did:identipay:<host>:<tx-id>Resolve
The wallet performs a deterministic HTTPS GET to fetch the full commercial proposal from the merchant's endpoint.
GET /api/identipay/v1/intents/<tx-id>Verify
Before signing, the wallet cross-references the resolved hostname against a decentralized Trust Registry maintained on the Sui blockchain.
TrustRegistry::verify(hostname) → ✓To prevent DNS spoofing, wallets cross-reference the resolved hostname against a decentralized Trust Registry maintained on the Sui blockchain. No intent is signed until the merchant's identity is verified on-chain.
Four steps.
Zero ambiguity.
From proposal to atomic settlement — every step is typed, human-auditable, and cryptographically bound.
Merchant proposes
A typed, canonicalized proposal — item, price, terms, expiry. Every field is explicit.
Wallet translates
Your wallet renders the proposal in plain language. You see exactly what you approve.
Send 1,299 USDC to TechStore.
Receive warranty (24 mo) + receipt.
You sign intent
A domain-separated signature bound to the proposal hash and context — not opaque bytes.
Atomic settlement
Value, encrypted artifacts, and compliance data settle in one indivisible transaction.
Two flows.
Same privacy.
Whether you're paying a friend or buying a coffee, every payment lands at a fresh stealth address. The flows differ in ceremony — the privacy guarantees are identical.
Send to a name, land at a stealth address.
Bob sends 50 USDC to @alice.idpay. His wallet resolves the name from the on-chain registry — two public keys, no address. An ephemeral key exchange produces a one-time stealth address. The money arrives at an address only Alice can detect.
Resolve name
Bob's wallet queries the on-chain MetaAddressRegistry and obtains Alice's meta-address — a pair of public keys (K_spend, K_view). No Sui address is stored or returned.
Derive stealth address
The wallet generates a fresh random scalar r, performs ECDH with Alice's viewing key, derives a one-time stealth public key, and computes the corresponding Sui address. This address has never existed before.
Transfer & announce
50 USDC is sent to the stealth address. A StealthAnnouncement event is emitted containing the ephemeral public point R and a one-byte view tag — enough for Alice to detect the payment without scanning every transaction.
Alice detects & spends
Alice's wallet filters announcements by view tag (eliminates ~255 of 256 candidates), recomputes the shared secret with her private viewing key, confirms the address match, and derives the stealth private key. She can now spend the 50 USDC whenever she chooses.
An observer sees two unconnected addresses with no on-chain link to @alice.idpay or to each other.
Built for engineers.
Designed for everyone.
Stealth meta-addresses: names, not addresses
A human-readable name (e.g., @krum.idpay) resolves to a pair of cryptographic public keys — never to a blockchain address. Every incoming payment is delivered to a fresh, one-time stealth address derived via ECDH. No two transactions share an address. No on-chain address is ever linked to the name. Value that accumulates across stealth addresses is merged through a shielded pool using ZK proofs, breaking on-chain linkage.
// Stealth address derivation (sender-side) // 1. Resolve name from on-chain registry(K_spend, K_view) = Registry.resolve("@alice.idpay") // 2. Generate ephemeral keypairr = random_scalar()R = r * G // 3. ECDH shared secretshared = r * K_view // 4. Derive stealth scalars = SHA256(shared || "identipay-stealth-v1") // 5. Stealth public keyK_stealth = K_spend + s * G // 6. Stealth Sui addressaddr = BLAKE2b-256(0x00 || K_stealth) // 7. Emit announcement (R, view_tag, addr)Real problems.
Protocol-level solutions.
Subscription Kill Switch
Cancellation is a human process. Pull authority remains until a merchant updates its internal state. You hope they comply.
Subscriptions are modeled as scoped delegate capabilities or recurring proposals. Revoke the delegate key or remove an allow-list policy — subsequent proposals fail on-chain deterministically.
Self-Enforcing Warranty
Paper receipts. Warranty eligibility is discretionary and error-prone. Receipts get lost. Proof of purchase lives in a drawer.
At a service desk, the wallet proves ownership of the warranty object and eligibility predicates. Repair authorization is a function of object ownership and terms — not paper receipts.
Corporate Compliance
Manually typed receipt data. Disconnected payment and ERP systems. Error-prone reconciliation across departments.
Transactions carry structured metadata — VAT category, merchant identifier, cost center — as commitments referenced by on-chain events. Indexers bridge into ERP with deterministic reconciliation keyed by intent hash.
Web2 in the front.
Web3 in the back.
Adoption shouldn't require merchants to rewrite their commerce stack. identiPay integrates at the boundary.
Frontend Plugin
Intercepts checkout. Generates a typed proposal. Displays QR or NFC handoff to the customer’s wallet.
Backend Listener
Monitors Sui for atomic settlement events keyed by intent hash. Confirms fulfillment in real-time.
Settlement
Receives USDC/EURC on-chain. Optional automatic off-ramp via regulated partners — outside protocol scope.
The Minimum Viable Product is natively anchored on the Sui Blockchain utilizing the USDC Corridor. A minimal identipay::settlement Move module accepts a Coin<USDC>, transfers it to the merchant, and atomically mints a ReceiptObject delivered to the buyer's one-time stealth address — unlinkable to their registered name.
Threat model.
Protocol mitigations.
Wallet compromise remains a critical risk — binding to EUDI-aligned credentials strengthens recovery but does not prevent an attacker who controls signing keys. Off-chain off-ramp processes introduce regulated counterparty risk and are intentionally out of protocol scope.
The full
technical specification.
identiPay — The Intent-Based Commerce Protocol. From pull payments to contextual, intent-driven atomic settlement.
By Krum Sultov · February 2026
Contents
- 1Introduction
- 2What Breaks in Today’s Payment Flows
- 3Protocol Overview
- 4Settlement Abstraction Layer
- 5Federated Routing & Resolution
- 6Stealth Identity & Privacy
- 7Push-Only Intent Engine
- 8Atomic Contextual Settlement on Sui
- 9Data Model: Commerce Artifacts
- 10Use Cases
- 11Integration Strategy
- 12Threat Model & Security
- 13Conclusion