Deployed addresses

Everything on this page is on Stellar testnet and anyone can look it up. Contract addresses are configuration rather than constants, and the authority is resources/deployment-testnet.json, which the release gates and the scheduled infrastructure check both read.

Contracts

The verifier and the registry are shared by both wrappers. Each wrapper binds exactly one underlying asset at construction, so a second private asset is a second wrapper.

Underlying assets

The USDC story is one asset end to end: the same Circle issuer whose Stellar Asset Contract the confidential wrapper wraps is what the swap trades and what the bridge mints.

The deployment record

The deployer holds no power over anything it deployed. The wrapper takes no admin argument and exposes no setter, and the verifier's two mutation methods refuse unconditionally.

Verification keys

Six keys, 1,760 bytes each, installed in the verifier at construction with no code path that can replace them. These SHA-256 hashes are pinned in extension/src/core/vk-hashes.json and reproduced from circuit source on every release.

These are the keys from OpenZeppelin's post-audit revision. The upstream demo's own testnet instance holds pre-audit keys, which is why Pocket deployed its own rather than pointing at it.

Reproducing them

bb write_vk \
  -b extension/public/vendor/circuits/target/circuit_register.json \
  -o /tmp/vk-out \
  --scheme ultra_honk --oracle_hash keccak
shasum -a 256 /tmp/vk-out/vk

bb must be exactly 0.87.0. The result matches the table above, and it must also match the vendored extension/public/vendor/circuits/vks/register.vk.bin byte for byte: a vendored key that disagrees with the reproduced one means the extension ships a key the circuit did not produce.

Release gate 2 does all of this for all six, checks each is 1,760 bytes, and additionally proves once and asserts the proof is 14,592 bytes. That last check catches something the hash cannot: an accidental zero-knowledge flag produces a 16,224-byte proof from the same verification key.

Proven on chain

How to check each of these yourself.

Keeping them alive

Soroban archives contract entries that go untouched. The verifier holds every verification key in instance storage and the library never extends it, so if that entry archives, every confidential operation on every wrapper pointing at it fails.

scripts/check-infrastructure.sh reads every id the deployment record declares, including the ones nested under confidentialAssets, and extends anything below 30 days remaining.

Testnet caps a fresh instance at 120,960 ledgers, about seven days. Mainnet's floor is 2,073,600 ledgers, about 120 days, so the thresholds are per-network and must not be calibrated on testnet.

./scripts/check-infrastructure.sh

Mainnet

No mainnet deployment exists. mainnet.confidential is empty in the network table, and every consumer guards on that rather than reading past the end. The path to mainnet.