Note: unlike regular posts, this is a more technical post intended for builders familiar with Farcaster protocol, Ethereum Attestation Service, and blockchain concepts.

About 2 weeks ago, we had a serendipitous conversation with the Optimism RetroPGF and EAS teams about Casts vs Attestations.

The topic was how to treat Casts and other public verifiable data in the context of building apps that create and consume interoperable attestations.

Background

Many builders have found Farcaster as a rich platform of thoughtful, crypto-native early adopters.

Increasingly, web3 builders are beginning to explore the frontiers of applications based around interoperable data. The emergent primitive for web3 data is the "attestation". Several apps, like CoLinks, Build, Give.eth, and Bountycaster have explored turning casts into EAS attestations.

What is the right model? While every builder should have the option to choose, the more ecosystem alignment around one architecture, the easier it will be for all of us to build useful apps around interoperable data.

Casts vs Attestations: which is better?

Jack and I have been talking about this idea for a while and because we want to treat basically everything in the world as an attestation, we want to focus on creating them on EAS only when necessary, but otherwise relying on the underlying data as sources of truth if we have strong guarantees on data availability and verifiability.

In short, we believe all casts are attestations, but not all attestations are casts.

But are EAS attestations better than Cast attestations?

The myth of onchain = better

First, let's narrow the scope of this discussion to offchain attestations.

Contrary to what some in web3 would have you believe, when it comes to attestations (or any data, really) about people, onchain is often an inferior place to initially register them.

While the data may still be public, there is a subtle but significant difference between public vs. onchain.

Onchain data is public and can never be deleted, while offchain public data is deleted all the time. Onchain attestations immediately cause problems with regulation like GDPR where users have the right to erasure. Even if you are not concerned with regulations, because of its permanence, the bar for issuing an onchain attestation should be higher in terms of importance and desired longevity, which we believe introduces friction in building app-like flows where we want to minimize cognitive friction for key actions.

Would you want a permanent public record of every minor profile tweak you've ever made? Would you think twice before updating your profile if you knew that tweak was going to be documented publicly forever? This cognitive friction gets in the way of building seamless apps that use crypto rails.

But that doesn't mean we have to forego onchain verifiability when using offchain attestations. With new protocols like Witness, we can actually achieve superior onchain verifiability and permanence by stamping offchain attestations onchain at whatever level of detail we like, while being able to preserve privacy and user control. All for a fraction of the cost (as 1m attestations can be rolled up into a single transaction which is indexed simultaneously across every blockchain). Therefore, when it comes to user data, we believe offchain attestations are usually superior to onchain.

OK, so Casts vs. (offchain) Attestations

Let's walk through an example.

Consider this cast:

compared with this offchain public attestation:

Both are me attesting that I endorse Jack for design.

If you look at the underlying Farcaster protocol data (you can use Neynar's Cast lookup and type in the cast URL: https://warpcast.com/web3pm/0xe2e0ea16), you can verify that this is a valid signed cast.

In both cases, you have a unique, deterministic fingerprinting system (a cast hash or UID, respectively), and you have a semi-decentralized network of indexing the content with different availability tradeoffs (Farcaster hubs vs IPFS).

However EAS attestations have a benefit of being tied to a specific schema, which improves interoperability and allows them to be onchain verifiable.

If we wanted to upgrade a Cast with these properties, we could envision have Icebreaker's @rec bot pick up the first "Cast" attestation and generate a second duplicate attestation in an "EAS" schema. However, this approach sacrifices provenance, because the original cast is verifiably from my account, while the attestation is proxied via Icebreaker. And we introduce a data doppelganger (the new attestation), which can lead to syncing problems.

There are ways around the proxy problem (e.g., using delegated proxy wallets, or frame-based EIP-712 signatures), but they all add complexity and/or UX friction, and don't solve the data doppelganger problem.

What we're doing for now

At Icebreaker, we believe there is a lot of powerful public + verifiable data already on Farcaster, just waiting to be reinterpreted in new, useful ways as attestations.

In order to "unlock" this data, we have two high level options:

Option 1: Treat casts as attestations without requiring them to be transformed. Simply need to be able to parse and interpret the casts. The casts remain the source of truth.

Option 2: Transform casts that fulfill certain criteria into full EAS attestations. The EAS attestations become the source of truth.

If we go with Option 2, then we also introduce a slippery slope. What types of data needs to be transformed into an EAS attestation for us to consider it valid for use in identity? Another non-EAS EIP-712 attestation? An NFT? A blockchain transaction?

Practically, we can always "upgrade" from Option 1 to Option 2 in the future, but it is very hard to "revert" from Option 2 to Option 1.

This is why we prefer to stay with Option 1, for now, until we encounter a compelling use case where we must do Option 2.

I.e., existing casts can be considered valid attestations as-is.

This is going to begin rolling out across Icebreaker over the next few weeks along with a series of other upgrades to be able to treat arbitrary external attestations as equivalent to Icebreaker-issued ones.

We believe identities inherently span multiple networks, and the best networking tool will let you to intelligently aggregate and traverse all your networks, instead of trying to lock you into just one.

-Dan, aka web3pm

PS. For builders getting started with attestations... Early on, we explored taking this idea to the extreme and forcing every attestation to be a cast. This model has advantages, in that your attestations are very public and can help with growth. In Icebreaker's case, we chose to stick with EAS for net new attestations for two reasons: not everyone among our intended audience (web3 builders) has or immediately wants a Farcaster account, and not every attestation should be public, while all casts currently are.

Therefore, we believe EAS currently offers the most flexible and interoperable model for net new attestations.