Is it necessary to restrict the resource input value to 0 or 1?

[abn2357]

In the old REPL mode: the four freeze/unfreeze balance interfaces (1.0 and 2.0) accept not only 0 (bandwidth) and 1 (energy), but also 2 (tron power). The README in the official wallet-cli repository also mentions this in some places like: "> freezeBalanceV2 [OwnerAddress] frozen_balance [ResourceCode:0 BANDWIDTH,1 ENERGY,2 TRON_POWER]". Since the mainnet has not enabled getAllowNewResourceModel, passing in 2 does not cause an error on the client side, but the node will throw a validation error.

In the recently new written standard CLI mode: the client directly restricts resource input to only 0 and 1.

Also, other staking-related API documentation based on java-tron all restrict resource input to 0 or 1.

[GordonLtron]

I highly agree with the stricter approach implemented in the new standard CLI mode (restricting to 0 and 1).

Since the getAllowNewResourceModel proposal is not yet active on the TRON Mainnet, passing 2 (TRON Power) will inevitably trigger a node-level validation failure anyway. Allowing invalid inputs on the client side only to have them rejected by the node degrades the User Experience and increases debugging confusion.

Aligning wallet-cli with java-tron's core staking APIs ensures consistency across the developer ecosystem. If the new resource model is approved and activated via committee proposal in the future, the CLI validation schema can be updated accordingly in a minor release. For now, a client-side "Fail-Fast" design is the safest choice.

[waynercheung]

Thanks for raising this. ResourceCode=2 (TRON_POWER) does exist at the protobuf level, but it is not universally valid for all staking-related contracts.

In java-tron, FreezeBalance/UnfreezeBalance and FreezeBalanceV2/UnfreezeBalanceV2 only accept TRON_POWER when AllowNewResourceModel is enabled on the target chain. Otherwise the node validates only BANDWIDTH and ENERGY. DelegateResource/UnDelegateResource accept only 0/1 regardless.

So the old REPL behavior was permissive pass-through rather than proof that 2 is supported on current public networks. The new standard CLI's current 0/1 restriction matches today's public-network behavior, but hardcoding it is not ideal for networks that enable the new resource model.

The better fix is to make validation network-aware:

• allow 2 only for the four freeze/unfreeze commands when getAllowNewResourceModel == 1
• continue rejecting 2 for delegation-related commands
• reject TRON_POWER for legacy delegated freeze cases
• update the legacy REPL help and README, which are currently inconsistent

[gummy789j]

Thanks for raising this, and thanks @waynercheung for the detailed analysis. We agree that deriving the validation from chain parameters (getAllowNewResourceModel) is the right approach — it keeps the CLI consistent with the node's actuator behavior and remains forward-compatible if the new resource model is activated on any network.

We'll roll out a fix covering:

1. Legacy REPL mode — correct the resource validation for the four staking commands (freezeBalance / unfreezeBalance and freezeBalanceV2 / unfreezeBalanceV2).
2. Standard CLI mode — stop hardcoding 0/1; instead validate the resource code dynamically based on getAllowNewResourceModel, so TRON_POWER is accepted only when the network actually supports it. Delegation commands remain BANDWIDTH/ENERGY only, matching the node.
3. Docs — update the README and related help text to reflect the network-aware behavior.

This is planned to ship together in the v4.9.7 release. We'll update this issue once it's out.

[GordonLtron]

@gummy789j
While the strategy to derive validation dynamically from getAllowNewResourceModel looks consistent on paper, the roadmap outlined for v4.9.7 introduces a severe architectural blind spot: Offline Transaction Construction (Cold Wallet Mode).

Before baking this implementation into the v4.9.7 release, the core team must clarify how the client-side validator behaves when wallet-cli is executed in an air-gapped or zero-connectivity environment.

The Offline Execution Deadlock:

1. Network Dependency in CLI Parsing: Forcing wallet-cli to perform an active RPC lookup (getchainparameters) during the initial command-line evaluation phase assumes the tool is always connected to a live FullNode.
2. Cold Wallet Disruption: Security-conscious enterprises and custodial infrastructures regularly use wallet-cli offline solely to generate unsigned raw transaction payloads. Under zero-connectivity conditions, this dynamic check will either trigger a connection timeout/hard crash or fail-safe by defaulting to deny ResourceCode=2.
3. Resulting Regression: This entirely breaks the ability to generate valid staking payloads for advanced resource models while offline, forcing an artificial online dependency onto a fundamentally stateless operations pipeline.

Necessary Defenses for the v4.9.7 PR:

• Graceful Degradation: If the RPC connection fails or times out, the validator MUST NOT block execution. It should fallback to a permissive state—allowing 2 for freeze commands—while printing a prominent console [WARNING] Node unreachable. Proceeding with permissive pass-through for ResourceCode=2.
• Bypass Flags: Provide an explicit override flag (e.g., --offline or --force) to bypass the dynamic chain-parameter validation entirely during raw byte assembly.

Let's ensure that fixing an online UX edge case doesn't inadvertently compromise low-level offline signing architectures.

[gummy789j]

@GordonLtron Thanks — that's a good point. To clarify the current state: wallet-cli does not yet formally support offline-only unsigned raw transaction payload generation, so there's no air-gapped construction path that this check would block today.

That said, it's a valid scenario worth factoring into future planning. For now, I think the cleanest approach is fail-open, defer to the node: the client-side resource check runs as a pre-flight UX check only when chain parameters are available, and simply skips when they aren't — leaving the node's validate() as the single source of truth at broadcast time.

To be upfront about the trade-off this implies: when chain parameters can't be fetched, we lose that one client-side pre-check. But since the node's validate() is always the final authority, the worst case is just a missed early hint — it will never let a genuinely invalid transaction onto the chain. That keeps the network-aware UX win online while staying compatible with an offline/cold-wallet path if we add one later.

[GordonLtron]

@gummy789j Appreciate the thorough consideration and the shift to a fail-open paradigm.

Deferring to the node when chain parameters are unreachable strikes the perfect balance—it provides proactive pre-flight guidance for connected users while fully preserving the stateless flexibility required for future offline/air-gapped architectures.

Thank you for the quick iteration and for factoring this into the v4.9.7 roadmap. Looking forward to the release!