EOA by default with socials/email

[luccamordente]

On Paradex we're looking to add support for socials and email as a way to authenticate users. To do that we're moving from WalletConnect v1 to Reown's AppKit.

Onboarding and authentication to Paradex requires the user to be able to generate deterministic signatures (given a constant payload, the same signature will always be generated).

Problem:

Deterministic signatures are not possible with Smart Accounts. We use EIP-712 signatures and non-deployed accounts generate ERC-6492 signatures. Also signers could eventually change, making signatures change too (if it's something supported by Reown Smart Account contracts).

When connecting with socials/email for the first time a Smart Account is given to the user as the default account. I can't see a way to change this behavior.

The only way we could continue the migration to Reown is if we can put the user on the EOA account by default.

Question / Request:

Is there a way or do you plan to allow changing the preferred kind of account (Smart Account vs EOA) given to the user when connecting to my app using AppKit?

[arein]

Hi @luccamordente - we ourselves have the same use-case and we use 6492 for the pre-deployed accounts. So not following why it would need to be an EOA?

I also assume that you want to enable social login which you currently don't have.

[luccamordente]

@arein can you expand on your use case?

The main requirement for us is that the account must generate deterministic signatures from pre-deployed to deployed state, during the entire lifetime of the account.

My understanding is that, given the same payload, the smart account can generate different signatures pre-deploy and after it's deployed. One of the features of smart accounts is allowing custom signature verification logic. This implies that there's no guarantee of a stable private key making signatures on behalf of this account, breaking determinism.

So even if it's possible to extract a ERC-712 signature from the ERC-6492 format, the ability to change signers can lead to catastrophic outcomes for a user if they change the signer of the account.

[arein]

Gotcha. We don't yet allow users to rotate the signers. We have a signer provided by our key management provider that is static. Once we allow adding signers then that would be in an additional transaction such that the bytecode and hence the address doesn't change.

TL;DR - no concerns for you to go ahead. I'll ask the team to add an FAQ somewhere so we document publicly how it's done.

[arein]

Also @luccamordente what app are you building? is it live?

[luccamordente]

@arein https://app.paradex.trade/ It's live for quite some time now.

We don't yet allow users to rotate the signers

I think my point is that there are no guarantees that rotating signers will not be possible in the future, is that right? Why would that not be a concern?

[arein]

It's a fact of how Smart Accounts work that we deal with such that you don't have to. If we enable the users of the embedded wallets to rotate/add signers then this will be done in an extra transaction in the batch of the deployment such that the bytecode remains static such that the address is the same as what was initially presented.

BTW can you please ugprade your SDK versions? I see you're running on v2.10.6 of the base dependency which is quite old

Happy to explain all this in a 10min huddle on the phone, too. cyberdrk on Telegram/Twitter

[irfanonk]

is it possible to disable smart account or make email account default?

[mbarr1111]

how to switch programmatically from smart account to EOA? for our use case smart account by default is killing us, we cannot use social accounts because of that so far.

[javaspeak]

I had thought this would work:

createAppKit({
adapters: [wagmiAdapter],
...generalConfig,
features: {
analytics: true,
},
defaultAccountTypes: {eip155: 'eoa'} // This is to avoid the Smart Account
})

However I still see the Smart Account in the accounts despot setting eip155 to 'eoa'

In my case I login using Google Login and then I realise that the default is Smart Contract.

When I switch to Google all is good and I can sign.

So my big problem is that until the user switches to Google I have issues when I wrap the provider in ethers 6 BrowserProvider and call functions lilke:

const provider = new BrowserProvider(walletProvider as Eip1193Provider)
const signer = await provider.getSigner();

If I switch from Smart Contract to Google everything works - however the end user may not know they need to switch to Google. The whole point of Account Abstraction is to make it easy for users, but now they need to switch account manually.

[mbarr1111]

also not working for me when using defaultAccountTypes.

[mbarr1111]

can we get an official response here?

[wot-Axel]

Apologize for not being able to solve the above problem, but I thought here are the people who can help me my own problem:

Subject: Erratic Canonical Address Derivation in AppKit/Magic Integration

Summary:
We are encountering a critical issue in the AppKit+Magic integration for our dApp: the same credential (Apple ID) sometimes yields different Ethereum addresses, violating the deterministic userID mapping required by our architecture.

Details:

• Our system design (see wot.id Core Principles) mandates that each human is anchored to a single Ethereum address, deterministically derived from their credential.
• In practice, logging in with the same Apple ID sometimes returns the correct canonical address, and sometimes an unwanted address
• This happens across browsers and sessions, with all frontend state cleared and no privacy relay or "Hide My Email" in use.
• All address state comes directly from AppKit/Magic; there is no frontend bug or cache involved.

Actions Already Taken:

• Cleared all browser storage and tested in multiple browsers.
• Confirmed consistent login procedure, credential, and project config.
• Added comprehensive debug logging at every address/connection state change.
• Used AccountDebugger and reviewed all AppKit flows.

Required Action:

• Coordinate with Magic to investigate and resolve this mapping drift.
• Ensure that only the canonical Ethereum address remains in the user profile; the unwanted address must be purged.
• Confirm that AppKit will always surface the correct canonical address for this credential in the future.

Impact:

• This issue undermines the core trust and uniqueness guarantees of wot.id and breaks the critical path for identity and attestation flows.

Greetings from Berlin

[evg-ch]

import { useAppKit, useAppKitAccount, useAppKitConnection } from '@reown/appkit/react'
import { useAccount } from 'wagmi'

const { address, addresses } = useAccount()
const { embeddedWalletInfo } = useAppKitAccount()
const { switchConnection } = useAppKitConnection({})

useEffect(() => {
if (embeddedWalletInfo) {
const isEoa = embeddedWalletInfo.accountType === 'eoa'
if (!isEoa && addresses.length > 1) {
const inactiveAddr = addresses.find((addr) => addr.toLowerCase() !== address.toLowerCase())
switchConnection({
address: inactiveAddr,
connection: { accounts: addresses.map((addr) => ({ address: String(addr) })), connectorId: 'ID_AUTH' },
})
}
}
}, [address, embeddedWalletInfo])