Sui Programmable Assets

Sui Programmable Assets, the object-centric framework on Sui's Move-powered blockchain, defines a dynamic, composable system for custom tokens using programmable objects and dynamic fields, enabling native support for compliance hooks, metadata attachments, and regulatory logic in RWAs. For Real World Asset (RWA) protocols, this standard is especially valuable, as assets can represent fractional claims on tokenized funds, treasuries, commodities, or other off-chain collateral while maintaining a compliant, interoperable interface for minting, transfers, updates, and hooks without traditional contract rigidity.

Before Programmable Assets, Sui RWA projects used basic Move resources, leading to inflexible data structures, fragmented compliance, and scalability issues in high-volume settlements. Programmable Assets resolved this by allowing objects to attach dynamic fields for arbitrary data (e.g., KYC proofs, legal terms), leveraging Sui's parallel execution (BAM) for instant finality (<400ms) and near-zero fees. For RWA builders, the standard provides a secure abstraction layer supporting off-chain oracles for validations, cross-chain bridges via ERC-3643 equivalents, and asynchronous updates, while enabling seamless composability with DeFi protocols like NAVI or Cetus.

Use of Programmable Assets in RWA Contexts

Programmable Assets is the foundational standard for RWA tokens on Sui because it abstracts the complexity of tokenizing and managing real-world assets into an object-oriented, Move-native framework. While traditional DeFi tokens wrap liquid assets like SUI for simple transfers, RWA tokens adapt the model to illiquid, regulated assets, tokenized private credit, commercial real estate, funds, or bond portfolios, where on-chain objects represent legally backed off-chain value held by custodians or SPVs, with dynamic fields for securities laws like Reg D or MiCA.

Key Applications in RWA Development

Fractional Ownership and Liquidity Provision

Many RWAs are high-value and indivisible (for example, a ten-million-dollar fund or a portfolio of private credit). Programmable Assets allows developers to create objects with dynamic fields for fractional shares, unlocking ownership and secondary-market liquidity under compliance rules.

• Implement object creation with fields for metadata, using hooks to restrict to verified addresses.
• Assets can trade freely on DEXs like Cetus, offering liquidity for assets that would otherwise be locked for years.
• Example: A fund token where dynamic fields embed Komainu custody proofs, with fractions for diversified ESG investments via R25 protocol.

Yield Accrual and NAV Management

Dynamic fields and hooks automate revenue distribution (e.g., yields from fund tokens), with oracle queries (e.g., Pyth) for real-time NAV updates. This supports auto-accrual without manual interventions, ideal for tokenized bonds or funds.

Using trusted sources (Pyth, Switchboard) ensures accurate fields, critical for compliance and for investor redemptions. Regulators increasingly expect transparent audit trails, and Programmable Assets provides this without exposing internal object state.

Redemption and Settlement Mechanics

RWA redemptions are inherently asynchronous, as physical settlement layers (banks, custodians, transfer agents) cannot finalize instantly.

Patterns include:

• Object burn with redeemer hook for queued claims.
• Compliance hooks for invalid transfers.
• Memo-required events for signed proofs.
• Proof-of-reserve checks before fulfillment.

Composability Across the RWA Stack

Programmable Assets plug directly into Sui DeFi:

• NAVI accepts assets as collateral within hook restrictions.
• Cetus pairs can provide deep secondary liquidity for permitted transfers.
• Aggregators route into Programmable Assets natively.

For regulated RWAs:

• Pair with hooks for investor eligibility gating.
• Combine with dynamic fields for modular compliance.
• Integrate identity proofs via fields.

Developer Advantages in RWA Builds

• Regulatory Alignment: Dynamic fields and hooks hide off-chain custodian processes while preserving accurate validations for MiFID II/MiCA-aligned disclosures.
• Extensibility: Object model and dynamic fields allow injecting RWA-specific logic i.e., pricing oracles, geofencing, or IPFS-pinned compliance policies.
• Risk Isolation: Assets remain fully Move compliant, burns do not impact wallet-held balances outside hooks.
• Upgrade Path: Sui's Move upgrades migrate via modules, preserving TVL and simplifying audits.

This diagram highlights how Programmable Assets acts as the connective tissue between on-chain object operations and off-chain asset realities. Creations attach fields proportional to contributed value, dynamic fields capture real-world compliance as transfers execute, and burn functions help manage redemptions during claims. For illiquid RWA portfolios, the model can be extended with explicit field modules between the module (M) and the custodian or SPV (C) to handle delayed settlement cycles.

Core Specification

A Programmable Asset must implement the Move module interface for its object-based structure, the dynamic representation of a user’s fractional claim on the underlying asset. Dynamic fields enable advanced features like compliance attachments, a valuable enhancement for RWA use cases where institutions manage data without needing full custom modules.

In Programmable Assets, the object behaves like any Move struct (balance queries, total supply via views, transfers), while dynamic fields refer to appended data for asset management. The specification enforces a clean separation between base objects and field params, ensuring predictable operations and seamless integration across Sui and RWA systems.

Key Definitions

• Object: The core Move struct for the asset, e.g., a tokenized fund or treasury share.
• Dynamic Field: The attached key-value pair (e.g., String -> bool for KYC), extensible for confidential proofs or fees.
• Total Supply: The aggregate asset value managed by the module, equal to the sum of principal, burned amounts, and adjustments for fees or losses.
• Hooks: Optional dispatch in functions (e.g., pre_transfer) providing idealized, rule-agnostic behaviors for UI, analytics, and oracle integrations. They represent the regulatory relationship between base assets and enforced logic.
• Function Calls: (e.g., transfer, add_field) Provide near-exact estimates of expected outcomes, reflecting fields, rounding, or NAV changes, without executing state updates. These enable accurate transaction planning.
• Rounding Rules: The standard mandates rounding in favor of the asset:
  • Round down when issuing tokens or deductions, preventing dilution.
  • Round up when applying fields or requirements, protecting existing participants. These rules ensure fair distribution and discourage precision-based attacks.

Programmable Assets define core Move modules with 20+ functions, organized by their roles in object logic, fields, and hooks. Every asset is created as an object via a single call, ensuring a single source of truth for behavior and movements. Below is the Move-equivalent interface, accompanied by developer notes covering edge cases, rounding behavior, and considerations specific to RWA assets such as asynchronous fields and oracle-driven updates.

1module sui::dynamic_field {
2    use sui::object::{Self, UID};
3    use sui::tx_context::TxContext;
4
5    public fun add<K: copy + drop + store, V: store>(uid: &mut UID, key: K, value: V) {
6        // Attach dynamic field
7    }
8
9    public fun borrow<K: copy + drop + store, V: store>(uid: &UID, key: K): &V {
10        // Read field
11    }
12
13    public fun remove<K: copy + drop + store, V: store>(uid: &mut UID, key: K): V {
14        // Remove field
15    }
16}
17
18module rwa_asset::rwa {
19    use sui::object::{Self, UID};
20    use sui::dynamic_field;
21    use sui::tx_context::{Self, TxContext};
22
23    struct RwaAsset has key, store {
24        id: UID,
25        balance: u128,
26        metadata: String, // IPFS URI
27    }
28
29    public fun create_rwa(ctx: &mut TxContext, metadata: String): RwaAsset {
30        let id = object::new(ctx);
31        dynamic_field::add(&mut id, string::utf8(b"KYC"), true); // Dynamic field for compliance
32        RwaAsset { id, balance: 0, metadata }
33    }
34
35    public fun mint(asset: &mut RwaAsset, amount: u128) {
36        // Pre-mint hook: Check dynamic field
37        let kyc = dynamic_field::borrow<bool>(&asset.id, string::utf8(b"KYC"));
38        assert!(*kyc, 1001);
39        asset.balance = asset.balance + amount;
40    }
41
42    public fun transfer(from: &mut RwaAsset, to: &mut RwaAsset, amount: u128) {
43        // Pre-transfer hook
44        assert!(from.balance >= amount, 1002);
45        from.balance = from.balance - amount;
46        to.balance = to.balance + amount;
47        // Post-transfer: Update field
48        dynamic_field::add(&mut to.id, string::utf8(b"Updated"), true);
49    }
50
51    public fun burn(asset: &mut RwaAsset, amount: u128) {
52        assert!(asset.balance >= amount, 1002);
53        asset.balance = asset.balance - amount;
54    }
55}

Detailed Function Breakdown (with RWA Developer Notes)

Below is a function-by-function explanation of the Programmable Assets interface, including edge cases, rounding behavior, and RWA-specific implementation guidance for regulated assets, off-chain settlement, and field-driven validation.

create_rwa

Creates the base object with initial dynamic fields.

• RWA Integration: For compliance-based assets, attach oracle-fed KYC (Pyth / Switchboard).
• Edge Case: Must handle duplicate fields (error: EFIELD_EXISTS).

mint

Increases balance, checked against fields.

• Formula: u128 math with rounding down.
• Usage: UI quoting, risk dashboards.
• RWA Note: Reflects pure regulatory mint, does not account for settlement delays or custody fees.

transfer

Moves amount from to to, with field checks.

• Ensures no precision-based arbitrage.
• RWA Note: Useful for compliant trades in regulated markets.

burn

Decreases balance.

• Return 0 for “no balance” on empty.
• RWA Note: Enforce redemptions, jurisdiction restrictions, or temporary pauses due to regulatory flags.

add / borrow / remove (dynamic_field)

Attaches/reads/removes key-value to object.

• Discrepancies vs create reveal field impact.
• RWA Note: Useful for quote generation in dynamic vaults or those with evolving fees.

Destroy (object::delete)

Removes object if balance zero.

• Requires prior check.
• Includes errors for non-zero (e.g., EBALANCE_NOT_ZERO).
• RWA Note:
  • For illiquid assets (such as funds and private credit): pair with burn asynchronous resolutions.
  • Trigger oracle checks for sanctions/residency validation.

Reference Implementation

Sui Foundation’s dynamic_field.move offers a mature, security-audited foundation for building programmable objects. The module integrates with Move runtime, providing a clean function surface for RWA-specific logic. Its design encourages minimal overrides while still supporting custom field models, metadata attachments, dispatch layers, and oracle integration.

Key capabilities include:

• Inflation Attack Protection: The implementation prevents dilution by enforcing object ownership and field invariants. Early creators cannot exploit low-supply corner cases to extract excess value.
• Rounding Compliance: All operations use u128 arithmetic for precise, deterministic operations that adhere to Move requirements of rounding in favor of the asset. This eliminates subtle precision-drift exploits.
• Extensible Fields: Dynamic attachments allow developers to embed RWA-specific functionality, NAV oracle checks, compliance gating, settlement status validation, or fee accounting, without modifying core logic.
• Flexible Structure: Programmable Assets build on Move’s base, with optional dispatch for regulated administration. This makes it straightforward to integrate custodial controls, upgrade pathways, or field-gated operations required in regulated RWA environments.

1module rwa_example::rwa_programmable {
2    use sui::object::{Self, UID};
3    use sui::dynamic_field;
4    use sui::tx_context::{Self, TxContext};
5
6    struct RwaFund has key, store {
7        id: UID,
8        balance: u128,
9    }
10
11    public fun create_fund(ctx: &mut TxContext, kyc: bool): RwaFund {
12        let id = object::new(ctx);
13        dynamic_field::add(&mut id, string::utf8(b"KYC"), kyc); // Attach compliance field
14        dynamic_field::add(&mut id, string::utf8(b"Terms"), string::utf8(b"ipfs://Qm...")); // Komainu custody link
15        RwaFund { id, balance: 0 }
16    }
17
18    public entry fun mint_fund(fund: &mut RwaFund, amount: u128) {
19        let kyc = dynamic_field::borrow<bool>(&fund.id, string::utf8(b"KYC"));
20        assert!(*kyc, 1001); // Hook-like check
21        fund.balance = fund.balance + amount;
22    }
23}

• The create attaches fields at txn time. For RWA assets, prefer dynamic fields for Komainu custody proofs and IPFS for terms.
• Objects can be extended for audit in UIs.

Create Flow (User-Facing)

User-level calls enforce fields with compliance.

1// As above in create_fund()
2// Pre-create: Field attachment for initial KYC

• Use tx_context for fee optimization.
• Override pre-create to add compliance checks (KYC, caps) and revert early if field fails.
• For illiquid or async-backed assets, combine create with provisional balance and oracle finalization to avoid over-issuance.

Transfer Flow

Symmetric to create, transfer invokes field checks then updates objects.

1public entry fun transfer_fund(from: &mut RwaFund, to: &mut RwaFund, amount: u128) {
2    assert!(from.balance >= amount, 1002);
3    from.balance = from.balance - amount;
4    to.balance = to.balance + amount;
5    // Post-transfer: Update dynamic field
6    dynamic_field::add(&mut to.id, string::utf8(b"Transferred"), true);
7}

• Field-first follows checks-effects-interactions and reduces reentrancy risk.
• For queued transfers, implement field to check status and push into a compliance queue.
• Add transfer rate limits or liquidity buffers to defend against sudden runs.

Burn Flow

Default burns are field-gated; RWA overrides query reasons.

1public entry fun burn_fund(fund: &mut RwaFund, amount: u128) {
2    assert!(fund.balance >= amount, 1002);
3    fund.balance = fund.balance - amount;
4}

• Burn uses balance for precision.
• Consider a time-bound field for redemptions.

Adding Dynamic Field (Example: KYC Update)

Field handling keeps execution consistent.

1public entry fun update_kyc(fund: &mut RwaFund, kyc: bool) {
2    dynamic_field::add(&mut fund.id, string::utf8(b"KYC"), kyc);
3}

• Keep field accounting transparent: Use events via Move logs and track via explorer.
• For RWA products, fields may fund legal overhead, document in on-chain strings.