> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcus.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Wrapped tokens

> How Arcus Spot RFQ represents stock tokens as upgradeable wrapped tokens that are minted as a fallback when no native fill is available, held in your account until the maker settles them, and settled by makers

Wrapped tokens are the **fallback delivery mechanism for [Stock Tokens](/concepts/spot-overview)** — not a separate product. When you buy a stock spot, a real fill against the stock token is always preferred; a wrapped token is only minted when no native fill is available (typically long-tail names).

A **wrapped token** is an on-chain representation of a stock token — for example `wTSLA` stands in for TSLA. Once minted, it is held in your Arcus account and behaves like the underlying for display, but is **non-transferable until the maker settles it to the real token**. The maker that issued it **settles** on a regular cadence. This lets the exchange offer equity exposure without requiring the underlying asset to be on-chain at the moment of every trade.

<Note>
  This page describes the smart-contract architecture and trust model. It reflects the **v1** design.
</Note>

## Factory and upgradeability

Each wrapped token is deployed by a **`WrappedTokenFactory`** as an upgradeable proxy. The proxy delegates to a shared **upgrade beacon**, which points at the current **implementation** (`v1`, `v2`, …). Upgrading the beacon migrates every wrapped token at once.

```mermaid theme={null}
flowchart LR
  Factory[WrappedTokenFactory] -->|Creates| Proxy[WrappedToken<br/>Proxy]
  Proxy --> Beacon[WrappedToken<br/>Upgrade Beacon]
  Beacon --> V1[WrappedToken<br/>Implementation v1]
  Beacon -.-> V2[WrappedToken<br/>Implementation v2]
  V2 -.-> Etc[etc...]
```

* **Upgrades are gated by a timelocked multisig** — no single party can swap the implementation, and changes are visible during the timelock window.
* Transfers **may be restricted** — for example, only whitelisted operators may move wrapped tokens. This keeps wrapped tokens inside the exchange's settlement perimeter (see [Trading and product UX](#trading-and-product-ux)).

## Minting: buying a stock

When a taker wants to buy a stock and no native fill is available, a maker supplies the wrapped token and the exchange mints it against the taker's collateral. (When a real fill *is* available, it is used instead and no wrapped token is minted.) Both sides express the trade as a **signed trade intent**; an **executor** pairs them and hands the matched order to the **Arcus Router**.

```mermaid theme={null}
flowchart LR
  Taker((taker)) -->|Signed trade intent<br/>WTB 1 TSLA| Exec[executor]
  Maker((maker)) -->|Signed trade intent<br/>selling wTSLA| Exec
  Exec --> Router[Arcus Router]
  Router -->|Look up registered<br/>wrapped token<br/>TSLA → wTSLA| Factory[WrappedTokenFactory]
  Router -->|Execute| Escrow[WrappedTokenEscrow]
  Escrow -->|Mint| WT[WrappedToken]
```

How each step works:

* **Executor** receives both signed intents — the taker's *want-to-buy* and the maker's *selling wTSLA* — and forwards a matched order to the router.
* **Arcus Router** executes an atomic swap, subject to satisfying both signed intents. It looks up the registered wrapped token for the underlying (`TSLA → wTSLA`) in the factory and **accepts `wTSLA` as a substitute for `TSLA`**. If no wrapped token applies, execution is delegated to downstream protocols (treated as a black box).
* **WrappedTokenEscrow** verifies the maker (seller) is **whitelisted** to issue wrapped tokens, then **mints the wrapped token and locks the taker's USDx in escrow**.

<Note>
  **Fungibility across makers.** The escrow can support multiple makers, with wrapped tokens fungible regardless of which maker issued them. Each maker is trusted to settle regularly. If a maker fails to settle, the maker is responsible for any difference between the price of the collateral and the current price of the stock token. There can be a loss — for example if the wrapped token appreciated since issuance — that someone else would have to cover to settle on its behalf.
</Note>

## Trading and product UX

After minting, wrapped tokens **behave like stock tokens inside the exchange** — but stay within the settlement perimeter until a maker redeems them.

* In the app, holding `wTSLA` **looks and behaves like holding TSLA** — it can be sold like any other position.
* The app **restricts withdrawing wrapped tokens off the exchange** and marks them as *“awaiting settlement,”* keeping them within the settlement perimeter until a maker redeems them.

## Settlement

A maker is expected to **settle on a regular cadence** (for example every 24 hours), **burning all outstanding wrapped tokens** it issued and reclaiming the escrowed USDx.

```mermaid theme={null}
flowchart LR
  Maker((maker)) -->|Settle| Escrow[WrappedTokenEscrow]
  Escrow -->|Burn and transfer| Taker((taker))
```

* To settle, say, **400 `wTSLA`**, the maker brings **400 units** to the contract as `wTSLA` and/or actual `TSLA`, and **receives the associated USDx** from escrow.
* When the maker brings **`wTSLA`**, the token is simply **burned**.
* When the maker brings **`TSLA`**, a holder's `wTSLA` is **burned and replaced with `TSLA`** — **no action is required from the wrapped-token holder**.

<Warning>
  **v1 trust assumption.** Makers may misbehave by not settling on time. The design relies on whitelisted, trusted makers: if a maker fails to settle, that maker is responsible for any difference between the price of the collateral and the current price of the stock token, and any unsettled position is a credit risk that must be covered to settle on its behalf.
</Warning>

## Trust model at a glance

| Property     | v1 behavior                                                                                                                                                     |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Who can mint | Whitelisted makers only, verified by the escrow.                                                                                                                |
| Backing      | Taker USDx locked in escrow until the maker settles.                                                                                                            |
| Fungibility  | Wrapped tokens are fungible across all issuing makers.                                                                                                          |
| Upgrades     | Gated by a timelocked multisig.                                                                                                                                 |
| Transfers    | May be restricted to whitelisted operators.                                                                                                                     |
| Settlement   | Maker burns wrapped tokens on a regular cadence and reclaims USDx.                                                                                              |
| Misbehavior  | Relies on whitelisted, trusted makers; a maker that fails to settle is responsible for the difference between the collateral and the current stock-token price. |