Skip to main content

Overview

RWA delegates add stateful, asset-specific risk controls to an accepted RWA. They are useful when an issuer wants Multiliquid settlement to enforce limits or operating rules beyond the token’s own transfer restrictions. MultiliquidSwap records whether an RWA has additional risk controls. When enabled, it calls the registered delegate immediately before settlement.

Optional by Design

An RWA can be accepted without a delegate when token-native controls and whitelist adapters provide the required policy.

Stateful Controls

Delegates can track volume, time windows, user state, or other protocol-specific limits.
Base contract: src/prod/RWADelegate.sol

RWA Controls in Context

Multiliquid separates three complementary control layers: Stablecoin delegates separately decide whether their LP domain accepts a given RWA and execute the actual token movement.

Core Interface

Both methods are callable only by the registered MultiliquidSwap contract in the production base implementation.

checkRWAIn

Validates an RWA entering a recipient account:
  • Stablecoin → RWA calls it for the receiver.
  • RWA → RWA calls it for the output RWA and receiver.

checkRWAOut

Validates an RWA leaving its source account:
  • RWA → stablecoin calls it for the user.
  • RWA → RWA calls it for the input RWA and user.
Returning false causes MultiliquidSwap to revert with RWAValidityCheckFailed. Concrete delegates can also revert with a more specific custom error.

Base Contract

RWADelegate provides:
  • UUPS upgradeability
  • Enumerable role management
  • Independent issuer-admin membership
  • Reentrancy protection
  • Issuer and protocol pause paths
  • Registered RWA ID, token address, and MultiliquidSwap address
  • Default pass-through implementations of checkRWAIn and checkRWAOut
Concrete RWA delegates override one or both checks with the issuer’s desired stateful policy.

ULTRA Delegate

The production ULTRA delegate enforces a per-address daily volume limit in both directions.

Volume Window

  • The same global dailyVolumeLimit applies to every address.
  • Each address has its own accumulated volume.
  • Both RWA inflows and outflows add to the address’s current total.
  • The accounting window resets daily at 06:00 UTC, corresponding to 14:00 Singapore time.
  • A zero limit disables swap volume through the delegate.
Before accepting a movement, the delegate computes:
The update is atomic with the swap, so reverted settlement does not consume volume.

Reads and Administration

getUserVolume reports the effective volume for the current window, the configured limit, and the next reset timestamp. Issuer admins set the global limit.

Event

Registration

An operator registers an RWA and its optional delegate through MultiliquidSwap:
Passing address(0) as the RWA delegate disables the stateful delegate layer. Passing address(0) as the whitelist adapter disables the protocol-level whitelist preflight. The RWA token’s native transfer behavior continues to apply in either case. setRWAAcceptance reads and stores the token’s decimals and supports tokens with up to 18 decimals.

Initialization

Concrete delegates initialize:
The Multiliquid admin and issuer admin must be distinct, nonzero accounts. Initialization assigns:
  • Upgrade and role administration to DEFAULT_ADMIN_ROLE
  • Stateful check access to the MULTILIQUID_SWAP_CONTRACT role
  • Issuer operating authority to the independent issuer-admin set
  • Protocol pause authority to PAUSE_ROLE

Pause Controls

Issuer admins control the issuer path:
Multiliquid’s PAUSE_ROLE controls the protocol path:
While paused, both risk-check methods stop, which prevents settlement through that RWA delegate.

Access Control

Next: Price Adapters

Learn how Multiliquid sources WAD-denominated asset prices