Rearchitecture tokens

[maznnwell]

A small summary of this PR:

• adds a chart and legend to show the balance available in tokens
• allows the user to search a token by name, owner and token standard also
• improves UI across token cards
• passes Git metadata through Dart-runtime environment variables (previously every build was changing the metadata.dart file, which created noise in commits)
• handles more clearly what a burnable token is

[maznnwell]

A preview of the finished worked.

[0x3639]

Thanks for the substantial this PR. The overall direction looks good. I (codex 5.6-sol) found four issues that should be addressed before merging:

1. The Utility checkbox is ignored when creating a token. The UI updates _isUtility.value, but the submitted model copies its existing isUtility value, so unchecking the option still creates an immutable utility token.
2. A failure writing to the local favorites box occurs after the issuance transaction has already been published, but it is reported as an issuance failure. Retrying could issue another token and charge another issuance fee. Local persistence failures should not replace the successful transaction result.
3. Changing the decimals slider after entering supply values does not revalidate those values or update the Continue button. The transaction can therefore use the new decimal count with validation calculated using the old count.
4. Token search only fetches the first RPC page—up to 1,024 tokens—so tokens on later pages cannot be found. It should paginate like AllTokensBloc or reuse its complete token list.

All current CI checks are green, but these cases are not covered by the existing tests. I recommend adding widget coverage for disabling Utility and changing decimals after entering supply values, plus tests for favorite-storage failure after publication and multi-page search.

[maznnwell]

Thanks for the substantial this PR. The overall direction looks good. I (codex 5.6-sol) found four issues that should be addressed before merging:

1. The Utility checkbox is ignored when creating a token. The UI updates `_isUtility.value`, but the submitted model copies its existing `isUtility` value, so unchecking the option still creates an immutable utility token.

2. A failure writing to the local favorites box occurs after the issuance transaction has already been published, but it is reported as an issuance failure. Retrying could issue another token and charge another issuance fee. Local persistence failures should not replace the successful transaction result.

3. Changing the decimals slider after entering supply values does not revalidate those values or update the Continue button. The transaction can therefore use the new decimal count with validation calculated using the old count.

4. Token search only fetches the first RPC page—up to 1,024 tokens—so tokens on later pages cannot be found. It should paginate like `AllTokensBloc` or reuse its complete token list.

All current CI checks are green, but these cases are not covered by the existing tests. I recommend adding widget coverage for disabling Utility and changing decimals after entering supply values, plus tests for favorite-storage failure after publication and multi-page search.

I've fixed and added tests for all the issues, with the exception of the second one.

I couldn't replicate it. If I understand correctly, there is an issue when adding a new token to the favorites box, after you receive the transaction that follows issuing a new token.

I manually tested that scenario and everything went on without an error.

Maybe ask Sol to reevaluate the scenario.

[0x3639]

Thanks — I rechecked the current head. The fixes and tests for issues 1, 3, and 4 look good.

Issue 2 is still present, but it will not appear during a normal manual test because the favorites write usually succeeds. It concerns the failure boundary after the transaction has already been published.

createAccountBlock() returns after publishing the account block. The subsequent favoriteTokensBox.add(...) is awaited inside the same try, so if that local write throws, the catch emits IssueTokenFailure. The UI then presents the issuance as failed and permits a retry even though the original transaction succeeded.

This can be reproduced deterministically in the existing bloc test:

when(
  () => favoriteTokensBox.add(any()),
).thenThrow(Exception('storage failed'));

Dispatching IssueTokenRequested will currently emit [IssueTokenLoading, IssueTokenFailure] after createAccountBlock has returned successfully. The desired result is for issuance to remain successful while the local persistence error is handled separately as a non-fatal error.

I recommend separating transaction submission from post-success local side effects, or catching the favorites-write error separately and still emitting IssueTokenDone.

[maznnwell]

Thanks — I rechecked the current head. The fixes and tests for issues 1, 3, and 4 look good.

Issue 2 is still present, but it will not appear during a normal manual test because the favorites write usually succeeds. It concerns the failure boundary after the transaction has already been published.

createAccountBlock() returns after publishing the account block. The subsequent favoriteTokensBox.add(...) is awaited inside the same try, so if that local write throws, the catch emits IssueTokenFailure. The UI then presents the issuance as failed and permits a retry even though the original transaction succeeded.

This can be reproduced deterministically in the existing bloc test:

when(
  () => favoriteTokensBox.add(any()),
).thenThrow(Exception('storage failed'));

Dispatching IssueTokenRequested will currently emit [IssueTokenLoading, IssueTokenFailure] after createAccountBlock has returned successfully. The desired result is for issuance to remain successful while the local persistence error is handled separately as a non-fatal error.

I recommend separating transaction submission from post-success local side effects, or catching the favorites-write error separately and still emitting IssueTokenDone.

This is fixed now.

[0x3639]

Thanks for the latest updates. The earlier issues around the utility checkbox, decimals validation, pagination, and persistence-error handling appear resolved.

I found two remaining issues:

1. The wrong token is added to favorites after issuance.

   state.accountBlock.tokenStandard is the token used by the issuance transaction, which is ZNN—not the newly issued ZTS. The integration test confirms this by asserting createdBlock.tokenStandard == znnZts and deriving the new ZTS from the block hash.

   As written, the flow favorites ZNN instead of the newly created token. Please derive the issued ZTS from the account-block hash, or include it explicitly in IssueTokenDone, and update the widget test to verify the derived ZTS.

2. main_dev.dart attempts to resolve an unregistered AllTokensBloc.

   The provider calls sl.get<AllTokensBloc>(), but setup() never registers that bloc. Launching through the included dev run configuration will therefore fail when MyApp builds.

   Please either instantiate AllTokensBloc(zenon: zenon!) directly, as main.dart does, or register it during dev setup.

The current CI checks are green, but I think these two functional issues should be addressed before merging.

[maznnwell]

I've fixed the issues, but added a TODO to the _sortTokens function.

I thing that the sorting of tokens, to show favorite ones before the others, does more harm than good. The automatic sorting should not happen, it should be a user intended, with a clear UI; using sort arrows for table columns, for example.

We can discuss about what to do with it later.