FIP: Permissionless Onboarding

[varunsrin]

WIP: Ideas to enable permissionless, decentralized onboarding

[varunsrin]

Permissionless Onboarding [Draft]

Farcaster’s next goal is permissionless signups so that developers can onboard users into their apps. Our identities must be:

1. Decentralized — a secure, unique id per user that maps to a key pair.
2. Recoverable — key pairs can be rotated and identities recovered if keys are lost.
3. Human-Meaningful — difficult to impersonate, has a a friendly username for each user.
4. Easy To Acquire — registration should be as inexpensive and fast as possible.
5. Spam Resilient — some protection against the legion of bots and farmers

Identifiers

Users must have a Farcaster ID or fid, which is a durable identifier included in every message. It’s important that this is not the username or key pair used to authorize messages which might change over the life of an account. Ideally, this is a random value that never changes and is never exposed in UI, but is the cornerstone of the user’s identity.

Current State

Fids are issued via the ID Registry contract on Goerli. A user can acquire an id and map it to an Ethereum address which is used to sign off-chain messages. These fids can be transferred to new addresses at any time. If migrated to mainnet, signing up would cost 50k gas or ~ $5 today.

Ideas

• Deploy the registry on an L2, trading security and stability for lower cost
• Keep the registry off-chain and centralized, and deploy to an L2 in the future

Names

Users must have a unique, human-readable username to make tagging and mentioning easy. Farcaster should support multiple namespaces since early ETH users might have an ENS and new users may need a cheap, starter name. It’s less important that this namespace is fully decentralized, since the identifier is the decentralized mechanism that ensures user security.

Current State

Fnames are acquired via the Name Registry on Goerli. A user can acquire an ERC-721 fname and associate it with an fid by placing it in the same address. If migrated to mainnet, signing up would require two transactions and cost ~150k gas which is about $15 at today’s prices. Farcaster also plans on supporting using ENS names if the user already owns one.

Ideas

The experience for new users without an ENS name can be simplified if we;

• Issue free domain-bound usernames like foo@farcaster.xyz or @foo.farcaster for all users who pay for an fid. Domain-bound names can be managed by a server for now and issued as ENS names on an L2 in the future.
• Issue free ENS sub-domain names like foo.farcaster.eth which can be managed by a server for now and issued on-chain in the future.

Wallets

Users need to have a wallet to register a new fid, but using a pre-existing wallet may be impractical:

1. They don’t have one.
2. Their wallet is on their ledger, at home.
3. Their wallet is on their desktop, and they are on their phone.
4. Their wallet is available, but isn’t connecting
5. They don’t trust FC yet, and would prefer not to have it touch their primary wallet.

The smoothest onboarding experience is for apps to create a new wallet for the user. Apps can either cover the cost of registration if it makes financial sense or charge the user in crypto or fiat. The downside is that users are very likely to lose the seed phrase to this wallet and we need a recovery system to protect them against loss.

Current State

Warpcast creates a new wallet for every user and pays for the gas costs on the Goerli network. It backs up the seed phrase to a key manager on mobile devices, which makes it less likely that the user loses their keys. The Farcaster Id Registry and Farcaster Name Registry contract implement a simple recovery system which allows another address to recover the fid and fname if list.

Ideas

A challenge is that the user starts with this new wallet as a throwaway hot-wallet, but it might accumulate assets slowly over time. The recovery system only recovers the farcaster identities and not other assets that may be in there.

• Deploy the wallet as a 4337 or other smart contract which allows multiple addresses to act on its behalf, enabling a recovery system. This increases gas costs but prevents user churn.

Storage Costs

If registration costs are kept low, its very likely that a large number of airdrop farmers or otherwise spammy accounts will join the network and flood the hubs. This is not ideal and may cause Hubs to run out of space and become very difficult to operate.

Current State

We do not charge for storage, assigning all users an identical amount which will become problematic.

Ideas

Users can pay for different tiers of storage with a yearly payment to a smart contract, monitored by the Hubs. The payment prevents hubs from being flooded by acting as a barrier to entry and also provides a spam-filtering signal for users of Farcaster.

Client Affordances

Clients can simplify onboarding by letting users signup with an email address. Their messages and likes can be “unverified” and not propagated across hubs until they acquire an on-chain identifier. This makes it easy for users to start playing around with the network before committing to a decentralized option.

Clients can also encourage users to sponsor other users by paying their registration fees. While this will only happen for some users, it is a very powerful signal that can be used to build a relationship graph.

[cboscolo]

If you do this:

Deploy the wallet as a 4337 or other smart contract which allows multiple addresses to act on its behalf, enabling a recovery system. This increases gas costs but prevents user churn.

How would it work for a user to authorize an application's Signer?

[varunsrin]

good q - hubs would just respect one or more of the authorized addresses as valid custody addresses which can produce a signeradd message

[cboscolo]

Assuming there was a way to determine a valid signing key from a deployed 4337 and the signing key was part of the 4337 init code, there is a tx cost optimization that could be made to use this 4337-address by delaying it being deployed it to mainnet or other L2s.
You just need to deploy it somewhere cheap that Hubs could use to determine the signing key.
Then, when the owner wants to manage any assets sent to the 4337-address, they would first need to pay to deploy it to that particular chain.

[tayyabmh]

I understand this will continue to be highly discussed topic. So wanted to jump in early on the conversation. Just to get to the point, my biggest concern with permissionless onboarding is Spam. At this early stage of the protocol, we need to plan for some adversarial behavior (as mentioned in Storage Cost)

• Combining your first and last points. ID's need to be decentralized, but client's can onboard without an fid (email) seems to be a bit conflicting. Clients may do as they please and have to make their own decisions. So, unless, you mean that client's are storing the data in a non-Hub location, I'd say fid's should be required to store on Hubs.
• As for should ID Registry chain location, what matters is "True Cost of Ownership" meaning if Ethereum gas fees are $10 and registration costs $10, TCO = $20. If you move to an L2, trying to achieve the same TCO should mean you get a similar amount of Spam prevention. If we expect Ethereum gas fees to stay high (more demand even after scaling), it may make sense to be on a secure L2 with a decent sized registration fee. TBH, this is one of the debates I've struggled with the most.
• Storage Costs can be built into TCO that I mentioned above. Yearly renewal should include an option to choose storage options.
• As for names, client's should have flexibility on what they want to do here. If a user wants a singular username across all of Farcaster they can purchase one with the Name Registry. ENS names should be ok to use as well, but can be a client decision.

Primary, takeaway for me is fid's should be required as some measure of spam prevention along with a potential storage cost selection option for users, with a minimum "free tier".

[varunsrin]

Thanks for the feedback.

So, unless, you mean that client's are storing the data in a non-Hub location,

Yes, if the user doesnt have an fid the hub won't accept it and clients cannot broadcast this outside of their own databases. It might help users get more comfortable with the product before paying to upgrade to an fid which gives them distribution to other clients. Not sure if this model is the right one, but I'm sure some client will experiment with this.

Storage Costs can be built into TCO that I mentioned above. Yearly renewal should include an option to choose storage options.

Agree on this

As for names, client's should have flexibility on what they want to do here.

Agree, but support from hubs with apis indexing the data makes it significantly easier for clients to implement

[maurerbot]

Would recommend OIDC complaint so FC id can be used as authn for other apps too.

Could do a progressive pinning to chain for purple check mark?

[betashop]

Hi @varunsrin thanks for this.

A lot to unpack here.

A couple of questions/thoughts. (More thinking out loud than providing any proposed solutions or concrete inputs at this stage.)

1. I'm very intrigued by this "Farcaster also plans on supporting using ENS names if the user already owns one." -- any more details on the thinking on this?

2. Regarding the worry of spam, i believe this is more of a cost of hubs issue than a user experience issue, correct? From a UX standpoint we should all be able to handle spam by personalizing experiences for users such that they only see what's relevant to them. There's concern that spammers reply spam too, but that also could be solved through UX (e.g. only show replies by default of credible users based on some user scoring, either off protocol or on protocol -- happy to help on this).

3. The way invites currently work is that a human (Dan) curates who to give invite powers to.
   Before we run go entirely permissionless, we could first (a) improve the invite process for existing users e.g. QR-codes, unique/expiring invite links, and (b) enable some of the humans at 3p apps (e.g. me) to curate who to give invite powers to amongst our users.

4. Regarding: "Warpcast creates a new wallet for every user and pays for the gas costs on the Goerli network. It backs up the seed phrase to a key manager on mobile devices, which makes it less likely that the user loses their keys. The Farcaster Id Registry and Farcaster Name Registry contract implement a simple recovery system which allows another address to recover the fid and fname if list." --
   Could an SDK be provided for this?
   Seems pretty straightforward for 3p apps to do with some specs.

Since recovery is a Farcaster contract, it would seem also that user could sign up from Jam and initiate recovery from Warpcast by calling the FC contract.

5. Since we are working with connected addresses already, I wonder out loud if 4 above could be extended to be a multisig where user could also intiaite recovery from one of their known authorized connected addresses.

6. As a next step, to also filter out spam:
   -rather than opening to everyone at first, we could open first to people with certain verified on-chain activities, such as attended an event (NFT ticketed), earned certain POAPs, holders of certain NFT collections. It wont be perfect but it's some filter. This could then be extended as we learn

7. We could also reverse the process. Rather than getting invited TO Farcater, you connect an address to see if you are approved based on your on-chain footprints

8. Just registering that I'm very against requiring users to pay for accounts right now. That will stunt growth before the network proves its value. I'd rather us find other ways to create friction/cost.

9. And I'm even more against 3rd party clients/apps paying. We don't have enough proof yet to invest in customer acquisition for the protocol or our apps. In the future when we have revenue to subsidize it, perhaps. But not in the near term.

10. Since most users don't eat up a lot of costs for storage, let's not penalize them. Rather we could enforce across the network fees to go above a certain level.

11. thinking about other ways of making the spammers pay without penalizing the good ones

And thinking through the whole mechanics more

[varunsrin]

I'm very intrigued by this "Farcaster also plans on supporting using ENS names if the user already owns one." -- any more details on the thinking on this?

See the FIP for ENS Support in Hubs

Regarding the worry of spam, i believe this is more of a cost of hubs issue than a user experience issue, correct

There are two problems - spam and DDOS. Spam is the UX problem of messages that are technically valid and reasonable at the hub level, but annoying to render to users. A DDOS is a situation where messages are generated such that they are causing storage or bandwidth problems for hubs.

Before we run go entirely permissionless, we could first (a) improve the invite process for existing users e.g. QR-codes, unique/expiring invite links, and (b) enable some of the humans at 3p apps (e.g. me) to curate who to give invite powers to amongst our users.

From a protocol perspective, I want to push towards fewer people having control of who gets onboarded. Consensus was already established in the last meeting around permission-less signups being the top priority for the Farcaster developers. Doing interim solutions was proposed and rejected a month ago since it would delay permissionless launch.

Since recovery is a Farcaster contract, it would seem also that user could sign up from Jam and initiate recovery from Warpcast by calling the FC contract.

Recovery can be set up and initiated from any application that has a wallet where the user has their custody address. So if Jam sets up a wallet for users this should definitely work.

Just registering that I'm very against requiring users to pay for accounts right now. That will stunt growth before the network proves its value. I'd rather us find other ways to create friction/cost.

And I'm even more against 3rd party clients/apps paying. We don't have enough proof yet to invest in customer acquisition for the protocol or our apps. In the future when we have revenue to subsidize it, perhaps. But not in the near term.

Registering an identity in a decentralized manner requires a blockchain transaction which will cost some money. Either users have to pay, or apps like Jam and Warpcast have to pay on their behalf, or we have to develop a less decentralized (i.e. non-blockchain) system that requires no payment at all. Which option are you advocating for?

[psatyajeet]

I came here to say that I love this set of proposed ideas @varunsrin . Thank you for putting it out.

I think it's makes the most sense to "Deploy the registry on an L2, trading security and stability for lower cost"

How easy is it to move a registry contract in the situation that the L2 turns out to have stability issues? That would be my primary concern. I'm not that worried about security for the FID contract on an L2. If I remember correctly, an L2 sequencer can't execute a transaction that is invalid. All it can do is censor transactions or re-order them. And if the sequencer wasn't processing transactions, users could always push the transaction to mainnet.

I also like the idea of allowing "Issue free ENS sub-domain names like foo.farcaster.eth which can be managed by a server for now and issued on-chain in the future". a LOT more users are using "decentralized IDs" on ENS because of *.cb.id and how easy coinbase made to set those up.

Generally, I do agree with folks saying that registration needs to be cheap in order for Farcaster to grow. Maybe something like $1-5/year would be fine (I think Whatsapp had a $1 signup fee which could prevent bots).

What kind of cost are you thinking here: "Users can pay for different tiers of storage with a yearly payment to a smart contract"? It seems like <10% of users have more than 100 casts. So if you charged a new user $1/year for their first 100 casts, it would cost a spammer $1/100 casts at a minimum. Seems like reasonable spam prevention? Then, maybe $1/month for 100-1000 casts?

[thebillzh]

This is me thinking out loud and trying to learn more:

(1)

Deploy the registry on an L2, trading security and stability for lower cost

L2 looks promising. Deploying on L2 should also increase protocol revenue since it can charge more while keeping the total cost (fee + gas) lower?

Speaking of protocol revenue, how much would be required to keep the protocol running? I imagine there would be a revenue cap beyond which it will stop charging users for registration.

(2)

The smoothest onboarding experience is for apps to create a new wallet for the user.

Just to make sure I understand this point, if a user wants to use their existing wallet, what would be the UX downside? They have to sign a couple txs when signing up or creating new signers?

(3) Re. spam prevention, I imagine we should be charging $ per cast (with a free tier) instead of storage. If someone wants to spam the network by replying to everyone, they probably don't care if their old cast will be purged due to storage limit.

Tagging and reactions should probably also have limits, otherwise the spammer could just send notification to everyone (this could be solved on a client level but we should put guardrails on the protocol level if possible)

[varunsrin]

L2 should also increase protocol revenue since it can charge more while keeping the total cost (fee + gas) lower?

Yes, the total cost will go down which can either be passed back to users or retained at the protocol level

if a user wants to use their existing wallet, what would be the UX downside?

You download an FC app because a friend told you about it. Now you start signing up and then you have to connect to your existing wallet. You may not have it on your phone. Even if you do, phone <> phone wallet connections are not super reliable. You have to switch over, register your fid, wait for it to complete, switch back, request a signer, switch back and then complete. Very high friction process.

(3) Re. spam prevention, I imagine we should be charging $ per cast (with a free tier) instead of storage.

would be ideal, but its much harder to enforce at the hub level (might even be practically impossible)

[thebillzh]

would be ideal, but its much harder to enforce at the hub level (might even be practically impossible)

Could you explain why limiting # of casts would be difficult?

And to check my understanding, limiting storage would only make old casts expire when a spammer tries to mass reply to everyone? People will still see notifications

[jessepollak]

Identifiers

Deploy the registry on an L2, trading security and stability for lower cost

From where I sit, L2s are ready for this use case. Yes, they have additional room for scaling and decentralization, but they have clear roadmaps and are progressing quickly.

Names

Issue free ENS sub-domain names like foo.farcaster.eth which can be managed by a server for now and issued on-chain in the future.

This would be my recommendation. There are a number of benefits to this, including:

• Farcaster names will work out of the box everywhere ENS is supported
• As a subdomain issuer, Farcaster can still have full control of resolution & economic mechanics through custom controller / registrar
• If someone onboards to crypto via Farcaster, they get a name out of the box that will work everywhere

Wallets

A challenge is that the user starts with this new wallet as a throwaway hot-wallet, but it might accumulate assets slowly over time. The recovery system only recovers the farcaster identities and not other assets that may be in there.

Deploy the wallet as a 4337 or other smart contract which allows multiple addresses to act on its behalf, enabling a recovery system. This increases gas costs but prevents user churn.

One idea that I have here is that we could make the Farcaster ENS name leverage EIP-6551 to have a account directly connected to it. That account could be configured at start to be controlled by the wallet you create, but then you could create a UX that would allow users to easily add other address for recovery. I believe this would be a very elegant way of adding multiple recovery addresses and beginning to think about the Farcaster name as more than just a name - actually a full enabled onchain account.

[varunsrin]

Thanks, but looking for a historical chart of trends over time (including spikes)

[psatyajeet]

I'd have to validate if this Dune query is accurate but the numbers seem ballpark correct: https://dune.com/queries/1210405/2073055

[jessepollak]

@varunsrin this is my canonical reference. A few notes:

1. L2 fees are consistently 10-20x cheaper than L1 fees, even in times of high demand
2. With 4844, fees will become more consistent because the L1 storage costs will have a separate market. Earlier this year, I would have projected this at a 10x decrease, but with the increasing usage of L2s, by the time this ships (Q3), it could end up being more like 3-5x reduction (which should still bring average transaction fee <$0.10.
3. Arbitrum currently has incrementally lower fees than Optimism because they have better compression, which is getting fixed in the upcoming Bedrock release (which will also be powering Base).

[varunsrin]

One idea that I have here is that we could make the Farcaster ENS name leverage EIP-6551 to have a account directly connected to it.

@jessepollak does 6551 work with all ENS names? my understanding is that it relies on ownerOf but this doesn't work for ENS that are resolved off-chain and even for ENS that are resolved on-chain but wrapped in the NameWrapper

[varunsrin]

after chatting with the ENS team, looks like they will work for on-chain 2LD's on the same chain, but cannot work for CCIP resolved names, since they have no natural onchain owner. since we can't expect all users to have an ENS registered on the same layer as the farcaster id, i don't think the 6551 approach can work for us.

[betashop]

Follow-ups from my previous comment and your response @varunsrin

1. With only 1600 WAU, now's not the time to be charging users. I don't think that's a realistic near term solution.
   It's a possible near term solution, but I don't think it's a realistic one.

2. As a developer building on Farcaster, with the current small user base and the amount of investment required to build quality apps and run hubs, there's no way I'm going to allocate additional budget to paying for user registrations at this point. It would have to be pennies not dollars for us to consider it.

3. I thus think L2 must be seriously considered.

4. I like a lot of @jessepollak 's thoughts FIP: Permissionless Onboarding #91 (comment) around L2 and also the wallet ux/recovery (sorta what i initially suggested but his is better) FIP: Permissionless Onboarding #91 (comment)

5. Ideally we would enable anyone to "bring" their onchain identity (e.g. ENS) and create an FID for it, or create an ENS for them.

6. My suggestions for interim solutions were wrt to any feelings that the challenges raised in your post were too much to solve in the near term. If so, we could do interim solutions while working on the harder problems.

[varunsrin]

As a developer building on Farcaster, with the current small user base and the amount of investment required to build quality apps and run hubs, there's no way I'm going to allocate additional budget to paying for user registrations at this point.

I thus think L2 must be seriously considered.

That's a fair point. I also want to point out that using an L2 might reduce the price by 50% ($5 to $2.50) but it won't make it pennies today. At the end of the day, storing data in a decentralized ledger costs money and someone has to find value in that and be willing to foot the bill (user or app developer).

[psatyajeet]

I think it'd be more than a 50% reduction.

A USDT transfer on Ethereum currently consumes 46,000 gas which would be $8-9 on L1 @ 80gwei gas costs and $0.26 on Arbitrum L2. It's still not "pennies", but anything <$1 feels meaningfully different.

I'm very excited about the L2 direction!

source: https://l2fees.info/

[psatyajeet]

EIP-4844 should reduce the cost of rollup transactions even further. Even assuminga world where gas costs 10x what it costs now, $2-3 is meaningfully more useable than $80-90.

[jessepollak]

Agree - L2s will be significantly more than 50% reduction, all of our modeling for Base has shown a consistent 10x+ reduction across all transaction types if you look at averages over the last year. This will only improve with increased compression and 4844 (notes above).

[davidfurlong]

Thanks I think this makes a lot of sense.

My north star here is how can we reduce friction, ideally abstracting away any crypto native terminology and costs.

I agree some costs act as a spam barrier, but getting each user to pay $10 may not be the best way to solve this problem, as it will inhibit adoption long term as farcaster grows beyond crypto natives. I understand these things will be adjusted over time, but I think ethereum mainnet gas fees are a major hurdle and the security of an L1 is probably not needed.

I suspect apps will want to maximize retention of users and demonstrate key value props of using their app over a permissioned alternative. Not posting the content to hubs seem contrary to this a little. I suspect apps will want to boost users at the start and post to hubs ideally and pay a tiny amount of fees for the user, and then if the users retains convert them to pay the full tx fee for registering an fname or similar.

Not sure how this translates to the protocol

[varunsrin]

Counterfactual Wallet Identity Approach

A user can sign a transaction to make a new smart contract wallet with a recovery system that allows a primary address (user's EOA) and a secondary address (friend, third party etc) to control assets in the wallet. Without broadcasting and paying for this transaction, the user can determine what address it will occupy using CREATE2. Assets can be sent here knowing that user can deploy the contract in the future and take control of the assets. Farcaster Hubs will treat signed messages from the primary address as valid messages on behalf of the smart contract's CREATE2 address.

The address of the counterfactual wallet can be used as the fid instead of using a numeric identifier. Since the address is a recoverable smart contract, it is much more durable than an EOA address which cannot be used as fid. Therefore a user can claim an fid without actually making an on-chain transaction. This design achieves three things:

1. It allows the user to avoid registering an fid, which saves ~ 25k gas
2. It allows all assets in the address to be recoverable by another address.
3. It simplifies the mental model around Farcaster Identities (no more “FID”)

How is a Farcaster account created?

• Alice securely generate a new ECDSA key pair whose address is 0x…123
• Alice generates a counterfactual transaction that deploys a smart contract wallet to 0x…ABC
  • Alice configures this so that 0x…123 has permissions to move assets in 0x…ABC
  • Alice configures this so that 0x…456, her ledger wallet, can also move assets
  • Alice’s “Farcaster ID” is now considered to be 0x…ABC
• Alice, or anyone on her behalf, calls a Farcaster Storage contract paying a fixed amount for storage
  • The Storage Contract emits an event indicating that 0x..ABC has paid the amount.
• Alice submits her counter-factual transaction to any Hub
  • The Hub has already seen the storage contract event, and accepts this transaction
• Alice can now use 0x…123 to generate signer messages.

How does Alice change her key pair?

If Alice wants to change her primary address to 0x…890, she can:

• Pay the full cost to deploy the smart contract wallet (~400k gas)
• Resign all her messages with 0x...890 and broadcast them to hubs
• Call a function to set a 0x…890 as the owner and remove 0x…123 (~50k gas)

How does Alice recover her key pair?

If Alice loses the keypair to 0x…123, she can:

• Find a copy of the signed transaction that was not yet broadcast
• Fund the 0x...123 address so that it covers the cost of the transaction
• Broadcast the transaction to deploy the smart contract wallet (~400k gas)
• Alice then uses her recovery ledger 0x…456 to remove 0x…123 as one of the owners (~50k gas)

What are the downsides of this approach?

The biggest drawback is that the complexity is high and there are more edge cases and migration challenges to worry about.

• All currently signed data will become invalid and need to restart on mainnet.
• Hubs and apps must upgrade to support new fid types, which is complex to orchestrate.
• Hubs must validate and store counterfactual transactions for users.
• Deploying wallets is likely to get more expensive over time, so encouraging it to happen sooner rather than later would be good.

[varunsrin]

Smart Contract L2 Identity Approach

A user can deploy a smart contract wallet to a specific L2 which houses the Farcaster ID Registry contract which can be used to claim an identifier. The smart contract specifies a primary EOA address which is the owner (which can be used to sign messages) and a recovery address which can take other actions on behalf of the wallet.

The benefits of this approach are:

• No FID migration is required, when compared to the counterfactual wallet system
• The recovery system can recover all assets, when compared to the EOA system.
• The overall cost is ~ 10x lower, when compared to an L1 system.

How is an account created on L2?

• Alice securely generate a new ECDSA key pair whose address is 0x…123
• Alice uses a Farcaster Wallet app to deploy a smart contract wallet (SCW) to 0x…ABC
  • Alice configures this so that 0x…123 has permissions to move assets in 0x…ABC
  • Alice configures this so that 0x…456, her ledger wallet, can also move assets
• Alice, or anyone on her behalf, calls a Farcaster ID Registry contract paying a fixed amount for an identifier
  • The ID Registry emits an event indicating that 0x..ABC owns an fid.
• Alice, or anyone on her behalf, calls a Farcaster Storage contract paying a fixed amount for storage
  • The Storage Contract emits an event indicating that 0x..ABC has paid the amount.
  • This can be done with the id registration in a single txn to save gas.
• Alice can now use 0x…123 to generate signer messages with her Fid.
  • The Hub has seen the id registry and storage events, and will accept these messages

How does Alice change her key pair?

If Alice wants to change her primary address to 0x…890, she can:

• Resign all her Signer messages with 0x...890 and broadcast them to hubs
• Call a function to set a 0x…890 as the owner and remove 0x…123 (~50k gas)

How does Alice recover her key pair?

If Alice loses the keypair to 0x…123, she can:

• Alice then uses her recovery ledger 0x…456 to remove 0x…123 as one of the owners (~50k gas) and set a new owner.

What are the downsides of this approach?

Relative to the counterfactual wallet approach:

• The net gas cost is higher (+25k) and it must all be paid upfront (~ 500k)

Relative to the EOA approach:

• Wallet code needs to be audited and secured, unlike an EOA.
• Additional cost per transaction due to wallet overhead.
• Claiming assets on other chains requires wallet deployments.

Relative to using L1’s:

• More risk with security and uptime relative to an L1.
• More risk of picking the “wrong” L2

What happens if we pick the “wrong” L2?

Assuming that another L2 crops up that has much better speed/security guarantees, there are two approaches:

1. Burn or invalidate the original contract, and redeploy the contract and initialize all state on the new L2, which may have significant gas costs.
2. Allow multiple namespaces for some period, requiring that all users eventually re-register on the new L2 which has a parallel namespace (e.g. foo:123 vs bar:123)

Open Questions

• How much would a recoverable smart contract wallet cost to deploy?
• How credibly secure are the L2’s? What do we look at to judge this?

Additional Notes

• If deployed using CREATE2, the wallet can also be deployed to all other EVM chains as necessary.

[varunsrin]

The first design decision we need to make is whether we want integer based fids or address based fids.

The decision of what wallet type to use — EOA, MPC, 4337, Counterfactual etc — is a second-order, client-level decision. Any wallet type can be used irrespective of the identity system used, though there is some slight variation in costs and features.

The main criteria for choosing between the two systems are:

• Migration — what is the process of moving from Goerli to new L1/L2?
• Portability — what is the process of moving to another L1/L2 in the future?
• Recovery — what wallet types allow fids to be recoverable?
• Gas Cost — what changes relative to the current gas cost of the system?
• Data Size — what is the impact to the size of user data?

Address-Based FIDs

A user begins by making a payment to the storage contract for an ethereum address, which becomes the user’s permanent identity. A smart contract wallet’s address can be used if the user wants this address to be recoverable. Hubs will accept any message signed by the ethereum address or by the valid owner of the Ethereum address according to the smart contract.

• Migration: Hubs and apps need significant refactors, some data loss for threaded casts
• Portability: Cannot re-initialize FIDs on a new EVM-chain, must create parallel fid system
• Recovery: Only smart contract or MPC wallets are recoverable, EOAs have no recovery
• Gas Cost: Counterfactual wallets are ~25k gas cheaper since no registry transaction
• Data Size: Each message is ~ 16 bytes larger increasing Hub size by ~ 200 GB / million users

Integer-Based FIDs

A user begins by claiming a unique integer from an on-chain registry contract and making a payment to a storage contract. The integer is assigned to a specific Ethereum address, which can change ownership to another address and nominate a recovery address. Hubs will accept any message signed by the ethereum address that owns the fid or by the valid owner of that Ethereum address if a smart contract is deployed there.

• Migration: No refactor or data loss, contracts are “re-seeded” on the new L1 / L2
• Portability: Can re-initialize on a new chain if inexpensive, or create a parallel fid system
• Recovery: All wallet types have fid recovery, slight increase in complexity since SCW’s can have overlapping recovery systems.
• Gas Cost: No change
• Data Size: No change

[varunsrin]

Integer-based fids seem significantly better because of the ease of porting them between chains and the greater flexibility with composing recovery systems for all wallet types.

[psatyajeet]

Seems like integer-based FIDs is a no brainer?

"Migration", "Portability", and "Recovery" all seem to have major downsides. The "gas cost" upside to address-based FIDs doesn't seem worthwhile if we end up choosing a chain that has low gas fees to begin with.

[michaelhly]

+1 for Integer-based FIDs

Is it also possible to include a contract method to "register" a range of FIDs in a single transaction? And then I assume the owner of the FIDs can transfer them to users however they like?

[michaelhly]

And ideally, we can establish various client onboarding patterns — applications should be allowed to completely abstract away FID registration away from the user

[musnit]

I think address-based FIDs have some unique benefits that should be considered before finalizing a decision on integer-based. I wrote this up in a separate FIP here: #102

[varunsrin]

closing this discussion since we are now officially on OP Mainnet. Thanks for all the input on this!