Decouple aens claim and preclaim transactions

[CedrikNikita]

This PR includes several improvements:

• fixes Bug registering name #661;
• fixes de-couple NamePreclaimTx and NameClaimTx in AENS claiming process #2200;
• fixes Improve text on modals (nonce error) #2645;
• user will no longer be able to preclaim exact the same name, while claiming name is in process (this currently results in infinite loading)
• an account that claims a name will no longer be blocked from usage during claiming process. It took up to ~5 minutes. (all other transactions while the name was in the claiming process were accumulated in a pending state and were not executed until the name was claimed);
• fixes an issue that caused the pointer to not be set to the current account if the user navigated off the page, closed the extension, and so on;
• allows to claim several names one by one without any problems;
• pending name now appears instantly, claimed name will also appear instantly in the wallet;
• reduces the number of name check requests;

---

Note

Medium Risk
Introduces persisted, auto-processed AENS claim queueing and pointer-update handling, changing how name transactions are created/signed and resumed across sessions. Risk is moderate due to on-chain transaction flow changes and new encrypted state persistence that could affect claim/pointer behavior if edge cases are missed.

Overview
Decouples AENS name registration into a persisted preclaim/claim queue (preclaimedNames) stored in secure storage and resumed automatically, so accounts aren’t blocked while waiting for claim mining and the process can survive navigation/extension restarts.

Updates the name claim UI to enqueue a preclaim (and prevent re-preclaiming the same name while it’s in progress), and updates the names list to show pending queued names immediately while preferring the owned entry once the name is active.

Adds queue processing in useAeNames to submit/rehydrate claim txs (reusing existing pending NameClaimTx when present), poll for mining, perform pointer updates for long names, and retry pointer updates without dropping the queued entry; includes new unit tests covering these scenarios.

^{Written by Cursor Bugbot for commit 4145a13. This will update automatically on new commits. Configure here.}

[github-actions]

Deployed to feature-decouple-aens-claiming-transactions.wallet.z52da5wt.xyz, artifacts

[github-actions]

Deployed to feature-decouple-aens-claiming-transactions.wallet.z52da5wt.xyz, artifacts

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Test mocks incorrect auction max length constant

Low Severity

The test mocks AE_AENS_NAME_AUCTION_MAX_LENGTH as 12, but in production (src/protocols/aeternity/config.ts) it is 12 + AE_AENS_DOMAIN.length which equals 18 (since AE_AENS_DOMAIN is '.chain'). This means the test uses a different threshold than production for deciding whether a name requires a pointer update. Names between 13–18 characters would incorrectly trigger pointer updates in tests but not in production, so edge-case tests around that boundary would give false confidence.

 

[cursor]

Stored blockHeight may be zero causing premature claim

Medium Severity

In addNameToClaimQueue, blockHeight is set to topBlockHeight.value, which is a polled computed value defaulting to 0. If the top header hasn't been fetched yet when preclaim completes, blockHeight is stored as 0. Later in claimName, the guard topBlockHeight.value < blockHeight + 1 becomes topBlockHeight.value < 1, which is almost always false, causing the claim to be attempted immediately—potentially before the required one-block delay after preclaim, leading to a failed claim transaction.

Additional Locations (1)

• src/protocols/aeternity/composables/aeNames.ts#L478-L484