[Bug] Live testnet vault predates migrate_adapter, needs redeployment

[collinsezedike]

Description

packages/contracts/vault/src/lib.rs has had migrate_adapter since #464/#507 merged into main. The live testnet vault at CONTRACT_ADDRESSES.testnet.vault (CBQYEHWIRJWIPWCJFQZAOP3VAZHRWFGAUS5GZHWFDDYKMFHJ5S3YS2Q5) was never redeployed since, and does not have it.

Verified directly against the live contract:

stellar contract invoke --network testnet --source <admin> --id CBQYEHWIRJWIPWCJFQZAOP3VAZHRWFGAUS5GZHWFDDYKMFHJ5S3YS2Q5 -- --help

lists deposit, withdraw, get_admin, is_paused, set_admin, initialize, set_paused, get_adapter, set_adapter, get_position, get_principal, get_entry_time, get_total_assets, get_total_shares. No migrate_adapter.

.github/workflows/verify-contract-addresses.yml's "Verify On-Chain Bytecode" job (required, blocking) confirms this with a hash mismatch, but only runs when packages/shared/src/constants.ts or packages/stellar-sdk-helpers/src/known-pools.ts change, so this has been silently true since #464/#507 merged without ever surfacing until an unrelated PR happened to touch constants.ts.

Steps to Reproduce

1. stellar contract invoke --network testnet --source <any> --id CBQYEHWIRJWIPWCJFQZAOP3VAZHRWFGAUS5GZHWFDDYKMFHJ5S3YS2Q5 -- --help
2. Compare against packages/contracts/vault/src/lib.rs's current public functions

Expected Behavior

The live testnet vault's callable methods match what packages/contracts/vault/src/lib.rs currently exports, including migrate_adapter.

Actual Behavior

The live vault is missing migrate_adapter (and possibly other changes made to the vault contract since its last deployment). pnpm verify:contracts confirms a bytecode hash mismatch between the deployed contract and a fresh build from current source.

Environment

Field	Value
Network	testnet
Wallet	N/A
Protocol affected	Meridian coordinator vault

Possible Cause / Fix

Run scripts/deploy-testnet.sh for a fresh vault (+ Blend adapter) deployment, then update CONTRACT_ADDRESSES.testnet.vault and KNOWN_POOLS.testnet["meridian-usdc"].contractId to the new address. This is a breaking cutover, not an in-place patch (no upgrade path exists on any of these contracts), so it needs the same care as previous vault migrations: announce it, and update every hardcoded reference (frontend, docs, any other tooling) together in one pass. Any existing testnet positions on the old vault are stranded once the pointer moves; users would need to withdraw from the old vault before the cutover if that matters for testnet usability.

Blocks #469 (the migrate_adapter keeper) from ever functioning against the live vault, independent of the still-open rate-source (#511) and DeFindex-adapter-activation gaps.

[Chigybillionz]

le me work on this during this program

[collinsezedike]

@Chigybillionz you're already on #513, and this would be your second active assignment on top of the others you've applied to here. Before I assign it, can you confirm you have the bandwidth to take this on now? It's a good one to prioritize either way, #515 and part of #511 are both blocked on this landing.

[blockchain-maxis]

Hi, I would like to work on this issue. I will run scripts/deploy-testnet.sh to deploy a fresh vault and Blend adapter, update CONTRACT_ADDRESSES.testnet.vault and KNOWN_POOLS.testnet to the new addresses, and update every hardcoded reference across the frontend, docs, and any other tooling in the same pass so the cutover is atomic and nothing is left pointing at the stale contract. I will announce the breaking cutover clearly in the PR description so testnet users know to withdraw from the old vault before the pointer moves, since existing positions on the old vault will be stranded once the address is updated. I will also verify the new deployment exposes migrate_adapter and all other current vault functions by running the --help check against the new contract address and confirming pnpm verify:contracts passes with a clean bytecode hash match before submitting. Can I be assigned?