> For the complete documentation index, see [llms.txt](https://docs.byzanlink.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.byzanlink.com/byzanlink-rwa-markets/launch-a-vault.md).

# 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