[code-bandit007]

Closes #1730
Closes #1731
Closes #1732
Closes #1733

Issues

#1730 Frontend: useWalletBalance does not handle token decimal places correctly

Category: Frontend - Bug
Priority: Medium
Estimated Time: 1 hour

Description:
useWalletBalance displays the raw i128 balance without dividing by the token's decimal factor. Users see a balance that is 10^7 times larger than the actual amount.

Tasks:

• Fetch the token's decimals() and divide the raw balance before display
• Format the display with the correct number of decimal places
• Add a test

#1731 Enhancement: escrow contract should support a configurable vesting duration per match

Category: Escrow Contract - Enhancement
Priority: High
Estimated Time: 4 hours

Description:
The vesting duration for payouts is a global protocol config setting. High-value matches may want custom vesting periods agreed upon at match creation time.

Tasks:

• Add an optional vesting_override_seconds: Option<u64> field to create_match
• Use the per-match override if set, otherwise fall back to the global config
• Update ABI snapshot and docs
• Add tests

#1732 Cleanup: contracts/escrow/src/lib.rs has duplicate use types::* import block

Category: Escrow Contract - Cleanup
Priority: Low
Estimated Time: 10 minutes

Description:
The top of lib.rs contains two consecutive use types::{ ... } blocks listing different fields. These should be merged into a single import block to reduce confusion.

Tasks:

• Merge the duplicate use types:: blocks into one
• Run cargo fmt and cargo clippy to verify no warnings remain

#1733 Test: admin_transfer two-step flow — propose, accept, and cancel paths

Category: Escrow Contract - Testing
Priority: Low
Estimated Time: 30 minutes

Description:
The two-step admin transfer (propose_admin / accept_admin / cancel_admin_proposal) has no dedicated test covering the full flow including the cancel path.

Tasks:

• Test full propose → accept flow
• Test cancel proposal: pending admin cannot accept after cancellation
• Test: non-pending-admin cannot call accept_admin

Summary

Issue #1730: the hook currently only reads the native XLM balance from Horizon; use 7 decimals for native XLM and fetchTokenDecimals for contract tokens. Keep the existing polling and render-time reset behaviour. Issue #1731: adding a parameter to create_match is an ABI-breaking change — update all internal callers (including create_match_with_conversion / create_match_with_referrer and any tests/fixtures that call create_match) and regenerate the ABI snapshot rather than hand-editing it. Issue #1732 is folded into the lib.rs step since both edits touch the same file; run cargo fmt and cargo clippy after merging the imports. Issue #1733: reuse the existing MockAuth/MockAuthInvoke patterns in admin.rs; no new test module is required if tests are added to the existing admin module.

Changes

• Fix the balance hook so it no longer returns raw on-chain integers. In useBalance, after loading the account, resolve the token's decimals (use fetchTokenDecimals from ../utils/tokenFormat, cached per token contract id; for the native XLM balance use 7 decimals) and convert the raw balance with formatTokenAmount. Return both the formatted display string and the raw value (e.g. { balance, rawBalance, decimals, loading, error }) so consumers can render a correctly-scaled amount. Keep the existing polling/reset behaviour intact. (frontend/src/hooks/useBalance.ts)
• Ensure tokenFormat.ts exposes everything the hook needs for issue Frontend: useWalletBalance does not handle token decimal places correctly #1730: formatTokenAmount (already present) and fetchTokenDecimals with per-token caching. Add a small helper if needed to format a balance with a fixed number of decimal places (e.g. formatTokenAmountFixed(raw, decimals, displayDecimals)), and make sure the decimals cache can be cleared for tests. Do not change existing exported signatures used by tests. (frontend/src/utils/tokenFormat.ts)
• Add unit tests for the decimal-aware formatting path: verify formatTokenAmount output for typical token decimals (7, 6, 18) and add tests for the new fixed-decimal helper if introduced. Cover edge cases: zero balance, whole amounts, and amounts smaller than one unit. (frontend/src/utils/tokenFormat.test.ts)
• Update useBalance tests to cover decimal handling: mock fetchTokenDecimals (or the token decimals lookup) and assert the hook returns a formatted balance (e.g. raw 10000000 with 7 decimals renders as 1), that decimals are fetched once and cached across polls, and that the existing 10-second polling test still passes. Reset the decimals cache between tests. (frontend/src/test/useBalance.test.ts)
• Update BalanceDisplay to render the formatted balance returned by useBalance (the decimal-adjusted value) instead of the raw string, keeping the XLM label and existing loading/error states. Ensure it still works when the hook returns null balance. (frontend/src/components/wallet/BalanceDisplay.tsx)
• Update BalanceDisplay tests to reflect the new hook return shape (formatted balance plus raw/decimals fields) and add a case asserting that a raw value with token decimals is displayed as the correctly scaled amount (e.g. raw 10000000 at 7 decimals shows 1 XLM). (frontend/src/test/BalanceDisplay.test.tsx)
• Add the per-match vesting override to the escrow contract. In types.rs, add pub vesting_override_seconds: Option<u64> to the Match struct. In lib.rs: (a) merge the two consecutive use types::{...} blocks into a single import listing all fields (issue Cleanup: contracts/escrow/src/lib.rs has duplicate use types::* import block #1732); (b) add an optional vesting_override_seconds: Option<u64> parameter to create_match (and the related create_match_with_conversion / create_match_with_referrer variants for consistency), store it on the created Match, and validate it if a minimum/maximum is enforced; (c) when computing the vesting duration at payout/claim time, resolve it as match.vesting_override_seconds.unwrap_or(config.vesting_duration_seconds) instead of always reading the global config. Run cargo fmt and cargo clippy afterwards to confirm no warnings. (contracts/escrow/src/lib.rs)
• Add the vesting_override_seconds: Option<u64> field to the Match struct in types.rs (with a doc comment explaining it overrides ProtocolConfig::vesting_duration_seconds when set). This is the type change required by the new create_match parameter. (contracts/escrow/src/types.rs)
• Regenerate the ABI snapshot contract-spec.json after the create_match signature change, following the procedure in CONTRIBUTING.md (stellar contract inspect on the rebuilt wasm). The create_match entry must reflect the new optional vesting_override_seconds argument; do not hand-edit other entries. (contracts/escrow/contract-spec.json)
• Add tests for the per-match vesting override: (1) a match created with vesting_override_seconds: Some(x) uses x rather than the global vesting_duration_seconds when computing the vesting timestamp; (2) a match created with None falls back to the global config value. Place these alongside the existing lifecycle/vesting tests and register any new module in tests/mod.rs. (contracts/escrow/src/tests/mod.rs)
• Add dedicated tests for the two-step admin transfer flow: (1) full propose → accept flow, asserting the admin changes and PendingAdmin is cleared; (2) propose → cancel → pending admin cannot accept afterwards (accept returns Error::Unauthorized); (3) a non-pending-admin cannot call accept_admin (authorization failure). Use the existing setup() fixture and MockAuth patterns already used in this file. (contracts/escrow/src/tests/admin.rs)
• Document the new per-match vesting override in the architecture docs: describe the vesting_override_seconds field on Match, note that create_match accepts an optional override, and explain the fallback to ProtocolConfig::vesting_duration_seconds when it is None. Update the create_match row in the contract function table accordingly. (docs/architecture.md)

[drips-wave]

@code-bandit007 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits