Campaigns and pre-deposit vaults

Level: Intermediate

Pre-deposit vaults

Time-limited vaults where users deposit to provide initial funding for a new chain or tokenized strategy. Outcomes: users receive a newly issued token, or can redeem their deposit on a new chain.

Technical shape (Predeposit implementation):

1. Users deposit on a source chain.
2. The vault locks; assets bridge to the target chain.
3. Users claim shares on the target chain via LayerZero messaging (same wallet address).
4. After launch, the vault type is typically succeeded by a Queued Withdrawal vault on the target chain.

Integrator gotcha: the cross-chain claim path bypasses the hook lifecycle, so a whitelist hook does not gate it - curators need separate gating.

Related implementations: Bridged Standard / Bridged Async add a one-shot unbackedMint for migrations; it requires totalSupply() == 0 and maxDepositLimit == 0, i.e. seed-time only.

Completed examples seen in docs/app: TAC-chain campaigns (TAC Stone, TAC LevelUSD, TAC Renzo), Stable network vaults (ctStableUSDT, ctStablefrxUSD), USDai DEX & MM (Arbitrum).

Campaign lifecycle

Campaign live ──► end date reached ──► controlled wind-down ──► withdraw-only

Completed campaigns are listed under Completed Campaigns in the app. When a campaign ends, deposits stop and you only withdraw.

Risks specific to campaigns

• Non-stable pairs and new chains raise impermanent-loss and liquidity risk.
• Bridging adds cross-chain messaging risk.
• Reward tokens may be volatile or illiquid.

Want to launch one? The docs point to Concrete's enterprise contact route; see Enterprise.