Skip to content
This repository was archived by the owner on Mar 17, 2026. It is now read-only.

feat(BA-2133): ENSIP-19 updates for registration flow for EOAs - #2594

Merged
amiecorso merged 10 commits into
masterfrom
amiecorso/ba-2133-registration-flow-for-eoas-in-web
Sep 10, 2025
Merged

amiecorso merged 10 commits into
masterfrom
amiecorso/ba-2133-registration-flow-for-eoas-in-web

Conversation

@amiecorso

@amiecorso amiecorso commented Aug 22, 2025 •

Copy link
Copy Markdown
Contributor

What changed? Why?
This adds the ability to register basenames (including signing to set the name as primary name in the L2ReverseRegistrar) for EOAs with the new ENSIP-19 compliant contracts.

Notes to reviewers

How has it been tested?

testingpostreviewcomments.mov
SurfaceError.mov

Have you tested the following pages?

BaseWeb

  • [] base.org
  • [] base.org/names
  • [] base.org/builders
  • [] base.org/ecosystem
  • [] base.org/name/jesse
  • [] base.org/manage-names
  • [] base.org/resources

@linear

linear Bot commented Aug 22, 2025

Copy link
Copy Markdown

@cb-heimdall

cb-heimdall commented Aug 22, 2025 •

Copy link
Copy Markdown
Collaborator

✅ Heimdall Review Status

Requirement Status More Info
Reviews ✅ 1/1
Denominator calculation
Show calculation
1 if user is bot 0
1 if user is external 0
2 if repo is sensitive 0
From .codeflow.yml 1
Additional review requirements
Show calculation
Max 0
0
From CODEOWNERS 0
Global minimum 0
Max 1
1
1 if commit is unverified 0
Sum 1

@vercel

vercel Bot commented Aug 22, 2025 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
base-web Ready Ready Preview Comment Sep 10, 2025 8:55pm

@amiecorso
amiecorso changed the base branch from master to arjun/ensip19-registration September 9, 2025 21:09
@amiecorso
amiecorso changed the base branch from arjun/ensip19-registration to master September 9, 2025 21:09
@amiecorso
amiecorso changed the base branch from master to arjun/ensip19-registration September 9, 2025 22:31
@amiecorso
amiecorso changed the base branch from arjun/ensip19-registration to master September 9, 2025 22:31
@amiecorso
amiecorso marked this pull request as ready for review September 9, 2025 22:33
@amiecorso
amiecorso force-pushed the amiecorso/ba-2133-registration-flow-for-eoas-in-web branch from 69cbf6c to 3e8c3a6 Compare September 10, 2025 00:10
Comment thread apps/web/src/hooks/useRegisterNameCallback.ts Outdated
Comment thread apps/web/src/hooks/useRegisterNameCallback.ts Outdated
Comment thread apps/web/src/hooks/useRegisterNameCallback.ts Outdated
Comment thread apps/web/src/hooks/useRegisterNameCallback.ts
Comment on lines +74 to +78
const [reverseSigPayload, setReverseSigPayload] = useState<{
coinTypes: readonly bigint[];
signatureExpiry: bigint;
signature: `0x${string}`;
} | null>(null);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This useState feels unnecessary since these values are only computed in registerName and don't depend on the react lifecycle

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I switched this to use a ref, which from what I understand helps persist a value across renders though doesn't trigger a re-render if the value changes. Are you thinking we don't even need a ref because the signature will be used immediately upon its creation?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you thinking we don't even need a ref because the signature will be used immediately upon its creation?

Yes exactly, we don't need these values to persist across renders since the transaction using the signature is initiated in the same function (registerName)

Also, it's generally safer to re-request the signature every time register is clicked because there's currently no cache invalidation implemented. So a flow like this could happen:

  1. User clicks register
  2. User signs the message
  3. User cancels the transaction
  4. User disconnects and connects a different wallet
  5. User clicks register
  6. This time there's no signature request and the transaction re-uses the wrong signature from the last wallet

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧠

Comment thread apps/web/src/hooks/useRegisterNameCallback.ts Outdated
Comment thread apps/web/src/hooks/useRegisterNameCallback.ts Outdated
Comment thread apps/web/src/hooks/useRegisterNameCallback.ts Outdated
@@ -185,11 +253,12 @@ export function useRegisterNameCallback(
return {
callback: registerName,
isPending: registerNameIsLoading || batchCallsIsLoading,

@arjun-dureja arjun-dureja Sep 10, 2025 •

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also return a loading state from the signature request here. useSignMessage exposes a status param you can use.

const { signMessageAsync, status } = useSignMessage();
const signMessageIsLoading = status === 'pending'
...
isPending: registerNameIsLoading || batchCallsIsLoading || signMessageIsLoading,

Comment thread apps/web/src/hooks/useRegisterNameCallback.ts Outdated
Comment on lines +203 to +205
chain: basenameChain,
account: address,
} as unknown as WriteContractParameters);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to pass these extra params? also is the type cast needed?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope, this is fixing an existing linter error around value : Object literal may only specify known properties, and 'value' does not exist in type 'ContractFunctionParameters'.ts(2353)

But I'm going to revert it to how it was because it doesn't break the build and isn't explicitly necessary for this change

arjun-dureja
arjun-dureja previously approved these changes Sep 10, 2025

@arjun-dureja arjun-dureja left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@cb-heimdall
cb-heimdall dismissed arjun-dureja’s stale review September 10, 2025 20:53

Approved review 3207715161 from arjun-dureja is now dismissed due to new commit. Re-request for approval.

@stevieraykatz stevieraykatz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

awesome work!

@amiecorso
amiecorso merged commit 7f18f38 into master Sep 10, 2025
11 checks passed
@amiecorso
amiecorso deleted the amiecorso/ba-2133-registration-flow-for-eoas-in-web branch September 10, 2025 22:55

This branch was successfully deployed

1 active deployment
Preview — 44109eb9 Deployed Sep 10, 2025 by vercel[bot]
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants