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.
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.
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?
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.
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.
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.
Icebreaker Labs
Had a discussion with @web3pm about attestations in Denver. Think there’s a lot to be explored here & super happy to hear EAS has an indexer that ‘just works’ Footy app will move towards this ASSUMING FC protocol doesn’t create more flexible app specific context-containers. Would be a shame to have multiple apps creating this same thing off hub/node which is what is happening now. App specific profile attributes, message types, links & reactions shareable across namespaces. The apps login to me. Why make an fc user enter their fav club more than once? We *must* break away from this wc feed centric thinking & go after devs where social is a feature not the core value prop.
Here's a post we did on casts vs attestations The TL;DR is both can be considered equivalent and we should adhere to the "minimize data changes" rule https://paragraph.xyz/@icebreakerlabs/casts-vs-attestations-which-is-better
🙌Good stuff. 2 things 1- wen FIP to add EAS schemas as FC message type? 2- Cryptowerk has a 1.2m hashes per second proof generator & then omnichain anchoring engine yada yada. In practice it’s less due to network. If this is of interest to you & your team hmu. Been looking for a reason to dust this off.
Thank you! Will check this out
“Would you want a permanent public record of every minor profile tweak you've ever made? “ https://paragraph.xyz/@icebreakerlabs/casts-vs-attestations-which-is-better
“…the more ecosystem alignment around one architecture, the easier it will be for all of us to build useful apps around interoperable data.” https://paragraph.xyz/@icebreakerlabs/casts-vs-attestations-which-is-better
My man @web3pm dropping heat 🔥 late at night! https://paragraph.xyz/@icebreakerlabs/casts-vs-attestations-which-is-better?referrer=0x2117bf88b4Cb0186eaA87500A045fc998290E42a
@j4ck.eth and I are building /icebreaker, the world's open professional network where you meet exceptional people. This week we shipped: - Events feed for all users - Split out sort & filter as part of massive SEARCH upgrade underway - Ability to add private note on ANY profile - Blogged on how we believe casts and attestations can more seamlessly interoperate (link 👇 ) - Launched @rec bot w/ @dylsteck.eth, demonstrating above. Any icebreaker user can make an attestation using farcaster where the *cast* is the source of truth, while being witnessed on over a dozen blockchains (see below) - Launched /colinks-and-co support, allowing attestations from many sources to be treated as equivalent in Icebreaker - Ingested the first luma event, users and prototype of our 2nd zkTLS flow 👀 - Lots of bug squashing https://paragraph.xyz/@icebreakerlabs/casts-vs-attestations-which-is-better https://app.icebreaker.xyz/credentials/Skill%3A%20Sales?show=givers&receivers=clsjqts2v02ey10vrp0qx7e0w
More information on the significance of creating interoperability between onchain and offchain data https://warpcast.com/web3pm/0xc90f7e2e
Failed. Too soon
Just published some thoughts on attestations including - why they are best served offchain - why casts are perfectly palatable https://paragraph.xyz/@icebreakerlabs/casts-vs-attestations-which-is-better Feedback always welcome!
Another great question from Twitter https://x.com/akashigami/status/1853939733405327626?s=46&t=e1zwxepdPy7mzQCs-2v42w
It took me so long to get to a minimum baseline for git passport and talent protocol … what mainstream user is honestly going to invest that much time and effort to become trusted … I feel like $degen AirDrop 1 is it perfect example of your point
Yes exactly We’ve thought a lot about this and concluded that part of meeting a user where they’re at means trying to find ways to honor their existing identity and data
What happens in the event that you or the hubs delete this cast cuz you ran out of storage? Does that mean this cast attestation would be lost? https://warpcast.com/web3pm/0xe2e0ea16
Great q! You *can* use a blockchain for this, but there are many other tools like ipfs you can use instead When icebreaker stores an attestation, we attempt to store and host a copy of the underlying data as a pseudo ipfs node.
Does having a pseudo IPFS node mean that data can still be deleted permanently if the user who owns it requests it?
Casts vs Attestations: which is better? asks @icebreaker https://paragraph.xyz/@icebreakerlabs/casts-vs-attestations-which-is-better?referrer=0x36de990133D36d7E3DF9a820aA3eDE5a2320De71