fuSUIon

fuSUIon is a cross-chain swap prototype that lets competing resolvers fill a maker’s order between Sui ↔ EVM using a Dutch-auction price curve and full or partial fills. On Sui (origin) the maker creates a pre-funded Wallet<T> shared object that holds funds and immutable order bounds (making/taking amounts, duration), a hashlock/Merkle root (full vs partial fills), and relative timelocks that gate withdraw/cancel phases. Any resolver can, over time, create a per-resolver EscrowSrc<T> that atomically debits the Wallet under those rules (price at now, fill amount, secret proof, safety deposit). On EVM (destination), a TypeScript order builder prepares a 1inch-style order, and TypeScript resolvers coordinate the destination leg with Solidity contracts (factory + proxy pattern) for settlement.

This design is Sui-native and time-robust: resolvers don’t need the maker online; they race on-chain, while the Move module enforces the price curve, Merkle-based partial fills, safety deposits, and staged withdraw/cancel windows. The contracts have been tested using Move tests for many partial-fill scenarios like incorrect indexes, multiple fills, incomplete fills etc. The cross-chain-swap demo is exercised on Arbitrum mainnet + Sui testnet; The TypeScript order builder drives the swap and talks to TS resolvers for both chains. Sui uses PTBs to compose object mutations; EVM uses 1inch Solidity contracts to create per-order proxy contracts and settle the other leg.

Sui Move package (escrow/): The core on-chain logic lives in Move. A shared Wallet<T> object holds the maker’s funds and immutable order parameters: order_hash, salt, maker/taker identifiers, making_amount (auction start/high), taking_amount (auction end/low), duration (ms), allow_partial_fills, parts_amount, a hashlock or Merkle root for secrets, created_at, relative timelocks for withdraw/cancel phases, and balances including safety deposits. Per-resolver EscrowSrc<T> and EscrowDst<T> shared objects track the portion being settled on each leg with a compact EscrowImmutables block, created_at, status, and balances. Timelocks are stored as relative windows (milliseconds) and resolved against the on-chain clock at execution time.

Lifecycle modules: escrow_create.move mints the Wallet (maker pre-funds) and lets any resolver create a source escrow by atomically debiting the Wallet under strict checks: current Dutch-auction price from created_at and duration, balance availability, safety deposit requirements, and either a hashlock (full fill) or a Merkle proof + index (partial fill). escrow_withdraw.move and escrow_cancel.move enforce stage-gated flows using clock::timestamp_ms: early windows are resolver-exclusive, later windows become public. Full fills require revealing the secret; partial fills verify specify secret for the index against the escrow hashlock. There is a rescue phase for Wallet/Escrow, after the public-cancel phase and a final delay to reclaim storage rebates and prevent state bloat. escrow_utils.move centralizes the Dutch price math (linear interpolation of taking amount over time), timelock validation, hashlack validation, index calculation, merkle verification, stage computation, and invariant checks. escrow_events.move emits lightweight creation/withdraw/cancel events designed to be indexer-friendly.

Off-chain orchestration (TypeScript, tests/): On Sui, a PTB-based integration builds and signs Programmable Transaction Blocks to create wallets/escrows and to execute withdraw/cancel in the correct stage windows; it uses the @mysten/sui client, transactions, and keypair utilities. The TypeScript order builder generates secrets and keccak256 hashlocks, computes auction bounds, and prepares the order domain; if a partner SDK import is unavailable, it falls back to manual hashing so CI and demos are reliable. On EVM, ethers-based helpers handle balances, approvals, and transactions. The destination-side interaction is designed to work with Solidity contracts that follow factory + minimal-proxy patterns for gas efficiency and per-order isolation.

Integration and demo setup: The demo is exercised against Arbitrum mainnet and Sui testnet. A TypeScript order builder drives the swap; TypeScript resolvers coordinate both legs. Sui uses PTBs to mutate Wallet/Escrow objects atomically at submission time. The EVM side uses Solidity contracts (including proxy patterns) to create and settle the destination leg.

Why these design decisions are better on Sui?

-Pre-funded shared Wallet<T> instead of replayable signed PTBs. Sui PTBs are tied to object versions; a pre-funded Wallet avoids stale signatures while enabling asynchronous resolver competition. It guarantees liveness with the maker offline and gives one canonical balance/nonce/parts map to enforce fills.

--Relative timelocks + on-chain stage machine. Using relative ms windows and deriving absolute gates from clock::timestamp_ms keeps the immutables compact and avoids “creation-time drift.” It cleanly separates resolver-exclusive and public phases on both chains.

--Dutch pricing computed in Move (no oracle). The module recomputes the current taking/making amount from created_at+duration deterministically, so every resolver faces the same price curve—no off-chain disputes, no desync.

--Merkle-root partial fills with index discipline. Compresses N secrets to one root; each fill proves membership and advances last_used_index. This makes partial fills cheap, parallelizable, and abuse-resistant without minting per-part objects.

--Safety deposits & rescue path. Deposits align incentives (discourage spam/abandonment) and rescue reclaims storage, so long-lived orders don’t turn into permanent state bloat—a direct fit for Sui’s storage-rebate model.

--Right primitive per chain. Sui uses PTBs to mutate objects atomically at submission time; EVM uses Solidity contracts + proxies to settle fills with the familiar allowance/permit tooling. Each side leverages its chain’s strengths.