# Deposit Semantics

Deposits into Multistake always begin and end on zkSync, even when the underlying capital will later be allocated to Monad or MegaETH. The protocol recognises three deposit pathways:

#### **1. Native zkSync Deposits**

A user holds assets directly on zkSync and deposits into the vault.\
This is the simplest path, as the assets arrive immediately.

Behaviour:

* Shares mint in the same transaction.
* totalAssets() updates instantly.
* No async lifecycle.

#### **2. L1 → zkSync Deposits via BridgeHub**

A user initiates a deposit on Ethereum L1. The deposit message is finalised after ZK proof verification on zkSync.

Behaviour:

* Shares mint only after the L2 receipt is confirmed.
* Vault prevents premature share creation.
* The deposit is fully synchronous *from zkSync’s perspective*, even though the bridge is async.

#### **3. Cross-Chain Deposits (non-canonical)**

If future versions support deposits sourced from other chains (e.g., direct Monad or MegaETH deposit wrappers), those deposits will still require confirmation on zkSync before minting.

Across all cases, the rule is simple:\
**Shares exist only after zkSync recognises finalised assets.**


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://multistake-1.gitbook.io/multistake-docs/documentation/oracle-architecture/deposit-withdrawal-semantics/deposit-semantics.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.