Skip to main content

​
Architecture

The identiPay protocol consists of 10 Move modules deployed on the Sui blockchain. These contracts work together to enable privacy-preserving, intent-based payments with zero-knowledge proofs.

Settlement

Atomic commerce execution orchestrator

Shielded Pool

Privacy firewall for coin merging

Trust Registry

Verified merchant identity database

Meta-Address Registry

Stealth identity name resolution

Announcements

Stealth payment detection events

Intent

Ed25519 signature verification

Receipt

Encrypted transaction receipts

Warranty

Transferable warranty NFTs

ZK Verifier

Groth16 proof verification

​
Contract Flow

A typical identiPay transaction flows through multiple contracts:
1

Merchant Registration

Merchant registers in the Trust Registry with their DID, public key, and Sui address.
2

User Identity Setup

User registers a name in the Meta-Address Registry using a ZK proof of government credentials.
3

Commerce Proposal

Merchant creates a signed proposal containing amount, items, and constraints.
4

User Intent Signing

User signs the intent hash with their Ed25519 key, verified by the Intent module.
5

Atomic Settlement

The Settlement contract executes atomically:
  • Verifies ZK proof via ZK Verifier (if age-gated)
  • Verifies intent signature via Intent
  • Transfers payment to merchant
  • Mints encrypted Receipt to buyer’s stealth address
  • Optionally mints Warranty
  • Emits Announcement for payment detection
6

Privacy Enhancement (Optional)

User deposits coins into the Shielded Pool to break transaction linkability.

​
Key Design Principles

  • All payments use one-time stealth addresses
  • Receipts and warranties are encrypted on-chain
  • Shielded pools break address clustering
  • Zero-knowledge proofs reveal only necessary predicates
The settlement contract uses Programmable Transaction Blocks (PTBs) to ensure either all operations succeed or all fail. No partial settlements.
Intent hashes are tracked in the settlement state to prevent double-spending of signed intents.
Most contracts are generic over token type <T>, supporting USDC, SUI, or any Sui coin.
Payment detection uses Sui events rather than address scanning, enabling efficient stealth address detection.

​
Module Structure

module identipay::settlement    // Core orchestrator
module identipay::shielded_pool // Privacy mixer
module identipay::trust_registry // Merchant verification
module identipay::meta_address_registry // Name resolution
module identipay::announcements  // Payment detection
module identipay::intent         // Signature verification
module identipay::receipt        // Transaction receipts
module identipay::warranty       // Warranty NFTs
module identipay::zk_verifier    // ZK proof verification

​
Deployment

All contracts are deployed as a single Move package with the identipay namespace. Shared objects (registries, pools, settlement state) are created during the init function and made globally accessible.
The contracts are designed for Sui’s object model, using owned objects for user assets (receipts, warranties, meta-address entries) and shared objects for protocol state (registries, pools, settlement state).

​
Next Steps

Integration Guide

Learn how to integrate with these contracts

API Reference

Explore the full API documentation

Build docs developers (and LLMs) love

Get started for freeTalk to us