[Bug]: The storage-deposit floor is a hardcoded testnet amount, 100× its documented value

Component

Other

Priority

P2

What happened?

ReviveClientWrapper.submitTransaction caps the storage deposit on every write with a hardcoded literal:

// Add 20% buffer to storage deposit, minimum 2 PAS
const minimumStorageDeposit = 2_000_000_000_000n;
let storageDepositLimit =
  gasEstimate.storageDeposit === 0n
    ? minimumStorageDeposit
    : (gasEstimate.storageDeposit * 120n) / 100n;

if (storageDepositLimit < minimumStorageDeposit) storageDepositLimit = minimumStorageDeposit;

The CLI works in planck, and DEFAULT_NATIVE_TOKEN_DECIMALS = 10, so 2e12 planck is 200 tokens, not 2. The comment is out by a factor of 100, and it names a testnet token on a path shared by every write.

Two consequences. storage_deposit_limit is a ceiling on what the caller can be charged, so setting it 100× too high removes the protection it exists to provide. And because no DotNS write comes near 167 tokens, the floor wins on essentially every call, so the estimate × 1.2 branch above it is dead in practice and the limit is never derived from the dry run at all.

Expected behavior

Native amounts are expressed in units derived from the chain's own tokenDecimals rather than assumed, so a floor documented as "2 tokens" is two tokens on whatever chain is connected.

Reproduction

2_000_000_000_000n / 10n ** 10n // 200n, against a comment claiming 2

Additional context

It may be worth doing further checks on all hard-coded constants that may depend on the specific chain.

Start at ReviveClientWrapper.submitTransaction and trace how the connected chain exposes tokenDecimals before reviewing related write or dry-run tests. Done means the storage-deposit floor is derived from the chain's native decimals, the documented two-token value is respected, and the estimate-based limit remains effective for writes.