Launch a Vault

This guide explains how partners launch a vault on Byzanlink RWA Markets, from strategy definition to deployment and optional white-label release.

Byzanlink RWA Markets is designed to let partners launch tokenised RWA vault products quickly using standardised vault frameworks, without building vault infrastructure end-to-end.

Who this is for

• RWA issuers and strategy partners launching vault products

• Platforms deploying vault strategies under their own brand

• Teams that want standardised ERC-4626 or ERC-7540-style vault behavior with sync or async flows

What you will deploy

A vault is an onchain smart contract that packages a tokenised RWA strategy behind a consistent interface.

Vaults can be configured as:

• ERC-4626 vaults (standard flows)

• ERC-7540-style vaults (request-based async flows)

• Synchronous or asynchronous operating modes depending on settlement requirements

Prerequisites

Before deploying a vault, partners should have:

1. Strategy definition A clear description of the underlying tokenized RWA strategy (e.g., treasury-backed, private credit, receivables).

2. Asset and denomination The token used for deposits (e.g., USDC) and the tokenized asset the vault represents or references.

3. Settlement behavior Whether redemptions settle immediately (sync) or through a request/settlement process (async).

4. Partner identity and attribution Display name, links, and vault metadata for the catalog.

Step 1: Define the strategy

Vaults are configured around a strategy that the partner operates.

At minimum, define:

• Strategy name (public)

• Strategy category (Treasuries, Private Credit, Receivables, etc.)

• Strategy summary (1–2 sentences)

• Any known operational constraints (settlement windows, batching cadence)

This information is used for vault metadata and discovery.

Step 2: Choose the vault model

Choose the vault model based on how the underlying asset behaves.

ERC-4626 (standard vault)

Use when:

• deposits and redemptions can be handled through standard vault flows

• settlement can be treated as relatively immediate at the vault level

ERC-7540-style (async request flow)

Use when:

• redemptions require a request period

• settlement happens on a schedule or in batches

• the underlying strategy has liquidity constraints

If uncertain, default to the model that matches the real-world settlement process rather than forcing synchronous behavior.

Step 3: Select operating mode (sync vs async)

Synchronous vaults

Use when:

• deposits and redemptions are executed without a request step

• settlement is operationally immediate

Asynchronous vaults

Use when:

• redemption must be requested and completed later

• cooldowns, batching, or settlement cycles are required

Async vaults are commonly used for real-world assets where settlement is not instantaneous.

Step 4: Configure vault parameters

Partners configure a vault through a structured setup. Parameters typically include:

Core parameters

• Deposit asset (token)

• Vault name and symbol

• Partner attribution (name, links)

• Strategy category and metadata

Operational parameters

• Sync vs async mode

• Settlement cadence (if async)

• Minimum deposit / redemption thresholds (if applicable)

• Deposit and redemption windows (if applicable)

Risk and constraints labels (optional but recommended)

• Liquidity profile label (e.g., immediate, scheduled, request-based)

• Settlement type label (sync/async)

• Strategy type tag (treasury, credit, receivables)

Vault parameters are designed to be explicit so vault behavior is predictable for users and integrators.

Step 5: Deploy the vault

Once configured, the vault is deployed using standardized vault implementations.

After deployment:

• the vault address becomes the canonical identifier

• vault metadata is published for discovery

• integrators can begin interfacing through standard deposit and redemption flows

Step 6: Publish to the vault catalog (optional)

Partners may list the vault in the Byzanlink RWA Markets catalog with:

• vault name, symbol, and category

• partner attribution

• mechanics labels (ERC-4626 / ERC-7540, sync / async)

• strategy summary

Catalog listing enables consistent discovery and integration readiness.

Step 7: White-label launch (optional)

White-label launch means partners can present the vault under their own brand and front-end experience while relying on the standardized vault framework.

A typical white-label launch includes:

• partner-branded vault page

• partner identity and strategy description

• deposit and redemption UX aligned with vault mode (sync/async)

• vault disclosure and risk notes suitable for the strategy

What partners control vs what the protocol controls

Partners control

• strategy design and operations

• vault configuration parameters

• branding and distribution choices

• disclosures and user experience (if white-labeled)

RWA Markets provides

• standardized vault frameworks

• consistent vault interfaces (ERC-4626 / ERC-7540-style patterns)

• catalog and integration surface

• non-custodial execution primitives

Next page

• Vault Types: ERC-4626 vs ERC-7540, sync vs async, and when to use each