v0.0.17 note deploy spends successfully on Shellnet 4.0.30, then rejects the newly deployed PrivateNote as non-current

[AndreaMangraviti]

Summary

dexdo v0.0.17 successfully deployed and funded a new N10000 SHELL PrivateNote while live Shellnet had already upgraded from 4.0.29 to 4.0.30.

Immediately afterward, dexdo note balance rejected the newly created note because the v0.0.17 binary still pins the 4.0.29 PrivateNote code hash.

This means note deploy did not fail closed before the wallet spend, despite the client being stale relative to the live RootPN generation.

Environment

• OS: Windows
• Network: Shellnet
• dexdo CLI: v0.0.17
• Manifest version: 4.0.29
• Live Shellnet version after deployment: 4.0.30
• Nominal: N10000
• Token type: SHELL
• Funding wallet: canonical multisig accepted by note deploy
• Contracts manifest: official deployed.shellnet.json from gosh-sh/dexdo-cli
• No seed phrase or PrivateNote secret is included in this report

Deployment command

dexdo note deploy
--multisig-address <REDACTED_MULTISIG>
--multisig-seed-file <REDACTED_SEED_PATH>
--nominal N10000
--token-type shell
--endpoint shellnet.ackinacki.org
--pool pn-pool-shell-4.0.30-v017-bb51-n10000.json
--json

Deployment result

The command exited successfully:

{
"schema": "dexdo.note_deploy.v1",
"status": "deployed",
"note_addr": "0:54b66d9b6ee2f75b977fa0b087ad2fd0f8c20ff841547a6037390259d9d68644",
"nominal": "N10000",
"token_type": 2,
"note_count": 1,
"error": null
}

The deployment log also reported:

• deposit voucher generated and proven;
• wallet submission checkpoint recorded;
• PrivateNote deployed;
• SHELL gas voucher generated and proven;
• pool entry reports shell_funded=true and native_funded=true.

Post-deployment failure

Immediately after deployment:

dexdo note balance
--note-addr 0:54b66d9b6ee2f75b977fa0b087ad2fd0f8c20ff841547a6037390259d9d68644
--contracts contracts/deployed.shellnet.json

Result:

Error: note 0:54b66d9b6ee2f75b977fa0b087ad2fd0f8c20ff841547a6037390259d9d68644 is not current PrivateNote:
actual code_hash c84845784612d76721be5a93120c27691158bb81306663b974a82b410cef758b,
expected code_hash 46239c6adea6cf767ec8e7ebcccc804bcb18370c000d2418e985c27510d8175b

Doctor result after deployment

dexdo doctor reports live Shellnet 4.0.30 and fails with:

• RootPN expected:
  187520fb02fef427dc16f8d8d703c301ef7251942364c98cfe2eeb30b8c658ce

• RootPN actual:
  dc69f70064115db2777b0dd762d1013ec79e7f80a3b975f0567312d3010c90e3

• RootOracle expected:
  4d415fddc899b9d1605289cc0ed515cdd800f49eef4919ac4dad79ebe02fd454

• RootOracle actual:
  5415cd020d7fcfa6f6b96121ea0af1aa423a75ea0ba11f4cddf2dfe974d44774

• PrivateNote expected:
  46239c6adea6cf767ec8e7ebcccc804bcb18370c000d2418e985c27510d8175b

• PrivateNote actual:
  c84845784612d76721be5a93120c27691158bb81306663b974a82b410cef758b

Doctor correctly classifies the binary as stale, but this validation occurred only after note deploy had already completed the wallet spend and deployed the 4.0.30 note.

Expected behavior

Before generating or submitting any funding voucher, note deploy should validate that:

1. the live SuperRoot/RootPN generation matches the binary’s pinned generation;
2. the resulting PrivateNote code hash will be accepted by the same binary;
3. the supplied contracts manifest is compatible with the live network.

If the binary is stale, deployment should fail before any wallet spend with a precise NETWORK_GENERATION_MISMATCH or STALE_CLIENT error.

Alternatively, if the deployed note belongs to the current live generation, note balance and other note commands should accept it through live RootPN discovery rather than a stale static pin.

Actual behavior

1. v0.0.17 deploys and funds a valid Shellnet 4.0.30 PrivateNote.
2. The same binary immediately rejects that note as non-current.
3. Balance, lock verification, trading, and withdrawal preflight cannot currently be performed with the release binary.
4. The user is left with funds in a newly deployed note that the installed CLI cannot manage.

Impact

This is a fund-access and release-transition safety issue.

Although there is no evidence that funds were lost, a stale release can spend from the multisig and create a note that it cannot subsequently inspect or operate. Automated clients cannot safely determine the note balance, locks, trading readiness, or withdrawal eligibility.

Questions

1. Is 0:54b66d9b6ee2f75b977fa0b087ad2fd0f8c20ff841547a6037390259d9d68644 a valid current-generation 4.0.30 PrivateNote?
2. Are the deposited N10000 SHELL and native gas recoverable once a 4.0.30-compatible client is released?
3. Should note deploy run the equivalent of dexdo doctor generation checks before any signed wallet submission?
4. Can note deploy fail closed when its pinned RootPN or PrivateNote hash differs from the live network?
5. Is a new release required, or is there a safe recovery command that can manage this 4.0.30 note now?
6. Should the installer or CLI refuse transactional commands globally when doctor detects that the binary is stale relative to live Shellnet?

Safety state

• No buyer or seller operation was started.
• Watcher and auto-buy were disabled.
• The new PrivateNote has not been used for trading.
• No withdrawal was attempted.
• Pool and recovery files were preserved.