Powering onchain legibility

At Once Upon, our vision is to make it far easier to build onchain legibility into consumer crypto apps. This post outlines how we’ll get there and the significant opportunities it will unlock.

TL;DR: Onchain legibility will drive the majority of future transactions. However, onchain legibility is hard for developers–expensive, difficult, and time-consuming, and a distraction from the problem they aim to solve. And it’s only getting harder with the complexities of a multi-chain, multi-address, multi-transaction-type world. Once Upon is making it easier for developers by making a great API as well as a block explorer for a full end-to-end developer experience. From there, we’re going to solve the problem of allowing users to transact within apps and build the best transaction engine. If this resonates, reach out!

Onchain legibility means understanding what’s happening–who, what, when, where, why, and how.

Legibility is critical because it’s what makes people transact: People do things onchain when they see and understand what others are doing onchain.

It’s a simple insight that sounds obvious in retrospect, but the industry hasn’t yet scratched the surface of its implications.

It’s surprisingly difficult to answer the questions around what is happening onchain, especially for multiple transactions at once.

The current developer experience for building a legible UX is painful–existing APIs specialize in raw data and limit developers to looking through the lens of a single address and a single chain.

As a result, most teams don’t even use existing APIs, opting to build their own infrastructure instead. This process is expensive, difficult, and time-consuming. Builders must:

• Find RPC providers and manage rate limits, or run nodes themselves.

• Orchestrate an ETL pipeline, which requires dealing with scale and building a custom context engine.

• Spin up and maintain their own database and create the optimal indexes for their application.

• Do a full backfill, scanning the entirety of all supported chains.

• And finally, wrap the database in an API to consume within their app.

This is all a distraction from the main problem they set out to solve–making a great consumer product.

The efforts to scale Ethereum over the last few years have hit an inflection point. There are tremendous benefits from cheaper block space. However, it has meant a greater variety of onchain activities, which makes it more complicated for developers to keep up.

There are three main types of complexity emerging: chains, addresses, and transaction types.

There’s an explosion of L2s and L3s. Crypto-native users are now proficient at switching networks and operating on many chains, which means data is scattered across single-chain data providers much more than before.

Cheaper blockspace has resulted in more information being stored onchain, which was previously prohibitively expensive. This means there’s much more data to index, which introduces scaling challenges.

Moreover, new L2s and L3s launch frequently enough that keeping up with all the new relevant chains requires constant attention and a sophisticated chain onboarding process.

As crypto is becoming more social and wallet authentication is evolving, the number of addresses the average user cares about is growing.

Social

Networks like Farcaster link social accounts to onchain addresses. For the first time, users rightfully expect to have a direct line into what their social circles (hundreds or even thousands of addresses) are doing onchain, thus informing their actions.

Personal

Moreover, your own onchain identity is getting fragmented. Auth platforms like Privy and Dynamic allow users to spin up many new wallets, making it harder to see a unified view of all of the user’s accounts. And EIP-4337 (Account Abstraction) introduces even more addresses that users control, some of which are smart contracts.

These social and personal trends mean we need to be able to query for hundreds of addresses at once. This isn’t possible with existing data providers, which are built to query only one address at a time.

New smart contract types

The last wave of crypto was almost entirely ERC20s and ERC721s. Today, cheaper blockspace is enabling creativity with new consumer crypto protocols that don’t adhere to early ERC standards (e.g. friend.tech, Ethereum Attestation Service). It can be difficult for teams to keep up with supporting and contextualizing new smart contracts as they are created.

Transaction sender abstraction

It’s now common for bridging tools and subsidized relayers to execute crosschain transactions on a user’s behalf, which makes it difficult to contextualize. 

These problems are most acute in the Farcaster ecosystem, where you’re dealing with all three of these complexities at once. Users are transacting across Zora, Optimism, Base, Degen, etc. They likely have multiple addresses linked to their Farcaster account and are playing with apps using embedded wallets. Every day, new apps and contracts are going to market within the Farcaster ecosystem. Payments are taking place with an offchain “token” called Warps. Frames are enabling developers to send subsidized transactions on behalf of users.

It’s now an insurmountable task to keep up with this complexity while building a consumer app.

Developers building on Farcaster deal with all three of these problems at once, but nearly every developer building for consumers struggles with at least one form of complexity (chain, address, or transaction type) at a given time. 

The Once Upon API is purpose-built for solving these problems. It’s the modern API for onchain data, built for consumer crypto devs. 

You can use the API directly or via our SDKs in the language of your choice.

The Once Upon API is self-serve. It’s free to get started, and you can upgrade for production-grade apps at scale. We succeed when our customers succeed.

You can use Once Upon to filter by multiple addresses, multiple chains, and multiple transaction types in a single query. We have the most powerful API endpoint for over 4 billion enriched transactions. New L2s and L3s are available for developers in minutes, not months. It’s all made easy to understand thanks to our open-source context engine (GitHub), which makes esoteric protocols approachable to newcomers. In addition, we have a toolkit of derived data endpoints for every question you might want to ask about people’s onchain behavior:

• Which addresses are associated with this address based on their onchain activity?

• What are the main trends happening in this subset of this ecosystem?

• How active have these addresses been over time?

• What are all the addresses that were involved in any way in this transaction?

• Show me asset transfers over time on every chain for these addresses and these tokens.

We’re constantly adding new chains and protocols to the API and powering more apps in the ecosystem, and the API only gets better with each one we add.

In addition to the API, we have a powerful multichain block explorer, preferred by many of the best builders, analysts, and operators in the space. It has especially resonated in the Farcaster and Superchain ecosystems. Once users invest time in learning the explorer, they tend to stick around forever.

The block explorer adds value for developers in several ways:

• The explorer acts as a jumping off point. For any data you see in the explorer, you can turn that view into an API query in a few clicks. Developers often start in our UI and then move to code.

• The explorer serves as living, breathing documentation for our API. Instead of describing how it works, developers can feel how it all works in production. This showcases the versatility of our dataset.

• By dogfooding and being users of our own API when building the explorer, we ensure we create the best developer experience.

• Seeing users of the block explorer “creatively misusing” the app informs where there are gaps in the market we can fill and what new API features to build next.

Looking ahead, our long-term view is that the best read engine will become the best transaction engine.

Letting a user transact based on what they saw their friends do can be complicated. A developer must:

1. Build the transaction with the right inputs for that protocol

2. Know when to copy the intent as opposed to using the protocol

3. Know when routing crosschain will create a better experience for the user

4. Show the result of the transaction to the user

For all four complexities, legibility is a critical component in order to do the transacting part well.

The next phase of our API is to abstract this complexity for developers via a simple and powerful transaction engine. This will allow developers to retain the attention of their users by letting them take action where they consume information. Seamlessly transacting in-app unlocks a new revenue stream.

This closes the loop, unlocking a flywheel where legibility leads to more transactions powered by Once Upon, which serves as the input for more legibility.

If our story and mission resonates with you, we are looking for ambitious people to join our team. Get in touch with Jordan and Paul on Farcaster—we’d love to chat.

Thanks to Gaby Goldberg for providing invaluable feedback on early drafts.