The vault contract is written and the transaction builder is live

[collinsezedike]

Two significant PRs merged last week that together close the most technically demanding part of Meridian's roadmap.

Soroban USDC vault contract (#66)
The MeridianVault contract is written and tested. Users deposit USDC and receive proportional mUSDC shares. Shares appreciate as yield accrues, so a second depositor after yield has been added receives fewer shares for the same USDC amount. Withdraw burns mUSDC and returns proportional USDC back to the caller.

The deposit function takes a Protocol parameter (Blend or DeFindex) resolved off-chain at call time. The user signs the routing decision before submission. Four tests pass: deposit_mints_shares, withdraw_returns_usdc, share_price_reflects_yield, and withdraw_more_than_balance_panics.

The contract is not yet deployed to testnet. That is the immediate next step.

Unsigned Soroban XDR builder (#78)
The API now builds real invokeHostFunction transactions. POST a wallet address, vault ID, and amount to /api/v1/tx/deposit and you get back a base64 unsigned XDR and a simulated fee. The transaction is simulated against the Soroban testnet RPC to populate the resource footprint before it is returned. A /submit endpoint forwards Freighter-signed XDR to the Stellar network and returns the transaction hash. The full sign-and-submit loop is wired up end to end.

vaultId from the client maps to the contract's Protocol enum: blend-* routes to Blend, defindex-* routes to DeFindex. The routing decision lives in the transaction the user signs, not in the backend.

What is next
The contract needs to be deployed to testnet. Once there is a live contract address, the deposit flow can be tested end to end with real USDC on testnet. If you are comfortable deploying Soroban contracts and running stellar contract deploy, that issue is open.

Issues: github.com/drydocs/meridian/issues

Back to building.
— Collins