
SVP Chain Testnet v9.9 Upgrade Announcement
SVP Chain Testnet plans to upgrade to v9.9 through on-chain governance. This upgrade introduces x/blockaddr, an on-chain address blacklist module that allows governance-approved restrictions on transactions initiated by specified SVP addresses.
Upgrade Schedule
This upgrade applies to SVP Chain Testnet and uses the on-chain upgrade name v9.9. It is planned for August 7, 2026. The governance proposal ID, voting schedule, upgrade height, release binary, and checksum will be announced with the formal upgrade proposal.
Once scheduled, the height returned by the on-chain upgrade plan is the sole authoritative upgrade height.
What's Included
v9.9 adds the blockaddr module and its state store. After the upgrade, governance can add or remove SVP addresses in batches through proposals. Each entry records the address, reason, addition height, addition time, and associated proposal ID.
When an address is blacklisted, the Ante handler rejects transactions associated with it, including:
- Cosmos transactions signed by the address;
- Transactions for which the address is the fee payer or fee granter;
- The
fromaddress of EVM transactions; - CLOB order placement, cancellation, and other transactions signed by the address.
The check runs before transaction execution, so transactions from blacklisted addresses are not included for execution in a block. The blacklist accepts only svp addresses, and governance controls additions and removals.
No historical blacklist entries are imported by this upgrade. The blacklist is empty immediately after the upgrade.
Impact on Users and Integrators
- Accounts, balances, positions, orders, and smart contract state not placed on the governance blacklist are unaffected.
- Standard Cosmos, EVM, and CLOB transaction interfaces remain unchanged.
- Transactions associated with a blacklisted address are rejected. Applications and integrations should handle the
address is blockederror. - The blacklist does not alter smart contract business logic. It restricts the transaction entry point for the corresponding SVP address.
After the upgrade, blacklist status can be queried with:
svpchaind query blockaddr blocked \
--node https://rpc-testnet.svpchain.org/ \
-o json
svpchaind query blockaddr is-blocked <svp-address> \
--node https://rpc-testnet.svpchain.org/ \
-o json
Requirements for Validators
- Vote during the governance proposal voting period.
- Download and verify the v9.9 binary before the upgrade height, and keep it at a separate staging path. Do not replace the binary used by systemd before the upgrade height.
- At the upgrade height, the old binary will stop with
UPGRADE "v9.9" NEEDED. Replace the binary and restartsvpchaindaccording to the coordinated upgrade plan. - The chain resumes at the upgrade height after validators representing more than two-thirds of voting power have completed the binary switch.
- Confirm the following log messages after restart:
Running v9.9 Upgrade...
Successfully completed v9.9 Upgrade
Post-Upgrade Verification
After the upgrade, verify that:
- The latest RPC height continues to advance and nodes are not catching up.
query blockaddr blockedreturns an empty blacklist.- Standard Cosmos transfers, EVM transactions, and CLOB transactions can be submitted normally.
- After a subsequent blacklist governance proposal passes,
is-blockedmatches the proposal content and transactions from the target address are rejected.
Important Notes
- Validators must not start a binary containing the
v9.9handler before the upgrade height, or the node will exit because the upgrade has not yet been triggered. - Validators must not use a binary without the
v9.9handler at the upgrade height, or the node cannot resume. - Always rely on the on-chain governance proposal,
upgrade plan, and the official release checksum. Do not use unverified binaries or an unconfirmed upgrade height.