Skip to main content

​
Devnet

The deployment carries the Trust Stake build. The upgrade extended the program data account from 244,088 to 329,664 bytes, and RiskConfig is initialised at 9JEJkGp3evd8wFAztEyjPLgTaRucThLyDJ5nkwdJg9ry. The devnet gate passes against it.
A vault opened by an older build cannot be deserialised by this one.Vault gained four fields — stake, reputation_bps, pending_unstake, unstake_unlock_at — and redeem_voucher gained the RiskConfig account. On devnet, open fresh vaults.

​
Redeploy checklist

1

Restore the program keypair

From ~/.config/solana/nelo/nelo_vault-program-keypair.json — see the warning below. Do not let a build generate a new one.
2

Build and deploy

If the program id does not match declare_id!, stop and restore the keypair rather than editing the id.
3

Initialise the risk config — once per deployment

redeem_voucher requires the RiskConfig PDA at seeds [b"risk"]. No voucher can redeem until it exists.Validated on the way in: stake_reference != 0 (it divides), hard_cap != 0 (a zero cap refuses every voucher on the platform), haircut_bps <= 10_000, unstake_cooldown >= 24h.
4

Re-run the devnet gate

It creates a fresh owner and its own mint each run, so it is self-contained. The harness initialises the risk config best-effort — on a chain that has seen a previous run, it already exists.

​
The program keypair

The program keypair is not in this repo, and must not be.target/deploy/nelo_vault-keypair.json is what controls the program address, and target/ is gitignored — so rm -rf target/ destroys it and anchor build silently generates a new one with a different address.The canonical copy lives at ~/.config/solana/nelo/nelo_vault-program-keypair.json. If a build ever produces a program id that does not match declare_id!, restore from there rather than editing the id.Before mainnet, that key belongs on a hardware wallet.

​
Authorities, and why they are separate

They are deliberately different keys. Publishing a stake price is an operation that happens often, and it must not need the key that can replace the program. update_risk_config carries an authority field, so rotation needs no extra instruction.
Three authorities were specified to be generated separately from the start — program, enrolment, risk. Keeping them apart after the fact is much harder than starting that way.

​
The apps

Both are Expo development builds. Expo Go cannot load them — @nelo/attest is a native module.
Neither has ever been built. The Kotlin in @nelo/attest compiles for the first time during that EAS build, and neither app has ever been bundled. Budget for the first build to fail on things no test can catch — see Testing for one that already did.
Check a handset’s capability without building anything:
StrongBox is API 28+ and absent on much budget hardware — which is the hardware this product targets. A handset without it degrades to online-only; that is an ordinary case, not an error.

​
Release

Not yet done, and week-4 work:
  • Signed release APK. Done when it installs from scratch on a handset that has never had a dev build, and completes a sale.
  • dApp Store publish. Requires a Publisher Portal account and a funded keypair.
  • Repo clean. git clone → pnpm install → anchor test green on a machine that has never seen the project. Done when someone outside the team does exactly that and it works.

​
Environment

Never commit a keypair, a mnemonic, or a real API key. .env is gitignored; keep it that way.