White-label tokenized vault on Stellar for assets whose value is attested rather than traded. Shares are a claim on an off-chain asset, so no price exists at the moment you act: entry and exit are requests. What you put in goes into escrow, the next accepted attestation prices it, and you claim the result.
Each operator deploys, configures and brands an independent instance.
Two rules the contracts enforce:
- Only approved addresses can enter — an allowlist maintained post-KYC.
- A priced claim always pays — neither a pause, a delisting nor a stale valuation can block an already-priced, funded cash claim.
- Product and architecture — what the protocol does, why it is asynchronous, and how the pieces fit together.
- Kit specification — invariants, deploy-time parameters, and complete role matrix.
- Testing — which tests cover storage and TTL, auth, ledger time, events and calls between contracts.
Pre-release, testnet only. Nothing here is audited or production-ready.
Testnet only. The deploy script rewrites the table below on every testnet
deploy from environments.toml → [staging.contracts], which is the record.
| Contract | Address |
|---|---|
async_vault |
CD5LYYXGOJ7R23P6D7YUN6DUJQYMI23KEUEOIFKXOSWOX3KHKTXRITED |
nav_oracle |
CBKVMUMIX7MXYHX5K34N5HYZOP6S2VGWF7MN27RIWBV3A3WD3X3L63CO |
share_token |
CDOISQTQRCYOTH6S3DFQ6UKJ2TEXLNO7NFIGOZS4RZL63IRCVXXCGP5N |
identity_verifier |
CCTCCY7AVFAIRGEWWJZT2UDMBHS3NGNKVUWLY43CHDNN75AQEV6P3EOY |
compliance |
CDEH6FJBK7NDFLALO3X3GDXZUREYHUSNC7ODPM64RBG3BBXW2USMW7OO |
asset |
CCOHKZLQ5EAD2A3RLHYHH7W4K2TNLNELXUVLWZIZALH45WXHH5H3QV7E |
One testnet transaction per investor-facing flow, executed through the live dApp against the contract IDs above.
| Flow | Entrypoint | Transaction |
|---|---|---|
| Connect wallet | — | n/a — no on-chain transaction |
| Deposit (subscribe) | request_deposit |
81e9c1a9…e590 |
| Claim shares | claim_deposit |
fe59e77e…e029 |
| Redeem (request) | request_redeem |
d6c02ee0…7524 |
| Withdraw (claim cash) | claim_redeem |
27a81778…db64 |
The Tranche 1 demo video was recorded on testnet against the team's E2E
testing deployment, deployed from main at 45e0e23 on 2026-10-20 (ledger
5299871). It is a separate instance from the one listed under
Deployed addresses. No contract source has changed on
main since 45e0e23, so its contract code is the same as main.
| Contract | Address |
|---|---|
async_vault |
CAGHFSATIJHNDXQA577APGG6GF2L7Q7KP6H2IUXVW6IT3CJ2OBE3QCEB |
nav_oracle |
CDDRBLB3GHZGKHGFATZBKFSXC6XRVFLHNPVWHTIE67FVNDYHU2RRRNRO |
share_token |
CCB23VF4CSI7QNWNDOAAAVOKOLWO5EEQFZIODWEXHS6OB3MMHGFZ3VA6 |
identity_verifier |
CDMV7DGGLGIWDWI4ERIBZ5YS2FZA3QVZPVUWCAWR5VBLVJMLFYCW6DML |
compliance |
CCCA6XDCXBZWWTIDYGLTL5GEHROCZTGYAIRAFA2KBO2JAWOJFU3TMZCB |
asset |
CAU7LDCUCLAWSJZS72B7VIPIE7FSN3T63D7MZMSSXTNLKYDYECVGH522 |
Test USDC: code USDC, issuer
GCUYFZRTNQ6WIIN5XBEYWVENKNVCBPK5BRXK4PDBCOGCYA4BZIRGMVIN.
Two ways to get a working toolchain.
nix develop # pinned Rust + stellar-cli + wabt/twiggy/tlaplus + prek
stellar contract build # build the contract wasms (not `cargo build` — OZ spec-shaking)
cargo test # run the workspace unit testsWith direnv + nix-direnv, echo 'use flake' > .envrc && direnv allow loads
the shell — and your editor's language server — automatically.
rustup show # installs the toolchain pinned in rust-toolchain.toml
rustup target add wasm32v1-none # Soroban's wasm target
cargo install --locked stellar-cli@27.0.0 # or: brew install stellar-cli
stellar contract build && cargo testFormatting and secret-scanning run on commit via a prek hook — see
.pre-commit-config.yaml and run prek install once.
From a fresh clone to a vault set deployed on a local network. Run these inside
nix develop, or with the toolchain from "Without Nix" plus Node 22 and Docker.
# A local Stellar network, RPC at http://localhost:8000/rpc
docker run --rm -d -p 8000:8000 --name stellar-local \
stellar/quickstart --local --enable core,rpc
npm ci # JS dependencies, including the harness
stellar contract build # contract wasms
npm run build:clients # TypeScript clients from the wasms
HARNESS_NETWORK=local npm run deploy -w scripts/harnessHARNESS_NETWORK defaults to local; testnet deploys to testnet and rewrites
the addresses table above. The local deploy funds its accounts from the
quickstart root key, so it needs no stellar keys identity.
The first deploy writes a secret key for each harness account to
.env.keys.<network> at the repository root, and later deploys reuse them. Back
that file up and never commit it. The
harness README explains how to use a
key you already hold for an account.
Output of a real run from a fresh clone. Contract IDs differ on every run.
> @strata-vault-kit/harness@0.1.0 deploy
> tsx deploy.ts
deploying to local (http://localhost:8000/rpc)
account keys in .env.keys.local (13 new)
funded 13 accounts; 0 already existed
asset contract CDKWXRAHPQVFOAEBOOWWR62ZXAE2IV4V47PATFN7IX4XDW5QIUUL7D2B
compliance CDGKQCYSMTDRBO7SYV3V72H6AMCQ3UNQFKUU4AD5GSU2I32XDYFS6F3U
identity_verifier CCZE76VWEWJ47NSFMIXCKU3L55CZZTI5JJY4CSYAWPO3WXPDFXUCA5G6
share_token CD6IA3BOPFX7VNADJ3GFK7IZGPVPNZA6HBCF425CNPSQ2GN7QZ3UUCP2
nav_oracle CAHD5ZKMIDD67ZEJUB5ACR62FMAYMQJ2KCRV2MBDNXWT7WEZ2VV3MRDD
async_vault CDQNMAZP7D5IA7AXZGK3XWYPFD2LDR6V5HQD2OLXZJYNQN4BMNN6SXWJ
clients generated
vault holds share_token manager role
vault is allowlisted
share_token bound to compliance
wrote deployed.local.json
The addresses land in scripts/harness/deployed.local.json; a later deploy
keeps the previous file as deployed.local.<timestamp>.json. Then run the
integration suites against that deployment:
npm run test:happy-path -w scripts/harness
npm run test:guards -w scripts/harnessBuilt on our own
stellar-vault-demo-dapp,
a working testnet demo. This repo is the productized version of it: code moves
across deliberately, with the roles, pause and configuration the demo never had.