FIP: Profile Tokens

[horsefacts]

Title: Profile Tokens
Type: Implementation FIP
Authors: v, horsefacts, tanishq

Problem

Users want to display their association with specific tokens as part of their social profile. For example, they may want to showcase their project’s app token, their creator coin, or their favorite token community. This already happens organically on social media through the use of display name emoji as symbols for specific tokens.

We propose storing a self-declared token association as a user data field.

Specification

Extend UserDataType with a new type, USER_DATA_TYPE_PROFILE_TOKEN.

enum UserDataType {
  USER_DATA_TYPE_PROFILE_TOKEN = 13; 
}

Users can only have one associated profile token at a time. To add a profile token, clients must set the string content of this field to a CAIP-19 asset URI. To remove a profile token, clients must set it to the empty string.

Validation

Clients should validate the format of this field before publishing messages to Snapchain.

Presentation

The CAIP-19 standard supports many chains and asset formats. Clients may select which chains and formats to support and should hide unsupported assets in their UI. To start, the Farcaster app will support EVM ERC20 and Solana tokens on the networks supported by Farcaster Wallet.

Interpretation

A profile token is a weak, self-declared, one-way association between a user and a token. Similar to the existing URL field, users may set their profile token to any supported CAIP-19 asset URI. Clients should not display or interpret profile tokens as ownership or verification without additional information. Clients may enrich profile tokens with additional data from external sources.

Rationale

Why not multiple profile tokens?

To keep it simple. It’s possible to extend this format if necessary in the future.

Why not a stronger association?
Profile tokens are meant as lightweight, self-declared affiliations, more like an emoji or link than a verification. Verifying ownership adds complexity and is a separate problem better left to clients.

Release

Farcaster app

We plan to start collecting and displaying profile tokens in the Farcaster app before protocol changes are live and publish these messages to Snapchain following the next release.

Farcaster protocol

This change is backwards compatible and can be included in the next Snapchain release.

Appendix: CAIP-19 examples

See the CAIP-19 standard for more information on asset IDs.

Mainnet ETH:
eip155:1/slip44:60

Mainnet WETH:
eip155:1/erc20:0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

Base USDC:
eip155:8453/erc20:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913

Solana:
solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/slip44:501

Solana USDC:
solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/token:EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v

[derekbrown]

Looks great; makes total sense. Glad to see the CAIP-19 format being used for this as well.
I get the desire for simplicity, but 100% think it should be an array of strings from the get-go (even if capped to length 1 to start).
I think the folks who will use this the most are power users and will want to associate multiple tokens with their profile.

[nuconomy]

Definitely worth taking it slower on this one IMO. I love the idea but can already see the "official" token support bot accounts being spawned offering "customer support" to less crypto-aware users. Might be good to show a verified badge if a verified address is the token deployer.

[derekbrown]

Might be good to show a verified badge if a verified address is the token deployer.

Love this concept.