Skip to content

Fix: Reject $ inside new token class keys and cap FetchBalances - #940

Merged
dzikowski merged 4 commits into
mainfrom
fix/hardening-followups-2
Oct 30, 2026
Merged

dzikowski merged 4 commits into
mainfrom
fix/hardening-followups-2

Conversation

@dzikowski

Copy link
Copy Markdown
Collaborator
  • A token class key field may contain $ only as its first character. createTokenClass rejects a $ later in a field, naming the field in the error. Without the check, such a class could be created, and then every transfer and balance operation on it would fail while building its string key. A leading $, as in existing tokens, still works.
  • An empty string-key part may only be the last part. Otherwise a + "" + b and a + $b would both produce a$$b. Every real caller (token class, token instance, mint request, mint allowance request, burn counter) builds its key from required, non-empty fields.
  • FetchBalances keeps its array response instead of switching to a page object. It returns at most 1000 balances (FetchBalancesDto.MAX_RESULTS) and stays deprecated in favor of a paginated balance query. The cap applies only at the contract endpoint. fetchBalances() itself is not capped, because allowance logic uses it internally and needs every balance.
  • Docs: the limit is in the DTO and method descriptions and in docs/exchange-integration.md.

dzikowski and others added 4 commits October 30, 2026 10:04
…parts

A token class key field may contain $ only as its first character, so a class that could not be
transferred is rejected when it is created.
An empty string key part may only be the last part, so a + "" + b cannot match a + $b.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
FetchBalances keeps returning an array of balances. It returns at most 1000 of them and stays
deprecated in favor of a paginated balance query. Internal balance lookups are not capped.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
@dzikowski
dzikowski merged commit 40fcfa9 into main Oct 30, 2026
13 checks passed
@dzikowski
dzikowski deleted the fix/hardening-followups-2 branch October 30, 2026 10:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant