Espra: An Onchain UI Layer for the Multi-Chain Ecosystem

Last updated by tav@espra.com on 2025-05-20

Today’s crypto ecosystem is fragmented across multiple chains, wallets, and apps. We’re building Espra, a unifying interface layer to solve this fragmentation.

Bitcoin made payments trustless. Ethereum made execution trustless. Espra makes the user interface trustless by bringing it fully onchain.
Our crypto browser provides a single, unified interface for the entire ecosystem, enabling users to seamlessly interact across chains without switching between different wallets and UIs.
Developers can build once and deploy everywhere, leveraging the unique features of each chain while providing their users with a consistent, unified experience.

Why Espra? Why Now?

Back in 2017, building a dapp was relatively easy. Ethereum was pretty much the only game in town. You wrote some Solidity, built a UI for it using Web3.js, and threw it onto some HTTP server.

Today, it’s a lot more intense:

You first need to choose between 100+ chains. Ethereum? Solana? Cosmos? Sui? Or maybe an L2 like Base? How do you choose? Even Sony has an L2 now.
But to really get those users you need to support multiple chains. How are you going to integrate with all of them? They each have different APIs and security models.
You need to decide which wallets to support. Maybe you want to enable account abstraction? Oh wait, not all wallets fully support that, and each chain implements it differently.
What about the onchain data that your app needs? You need a bunch of different indexing services — often costings thousands of dollars a month — just to access your app’s data.

This increasing complexity isn’t just a problem for builders. Each new chain and wallet adds another layer of friction for users, who must navigate an increasingly fragmented ecosystem.

A typical DeFi user today might need to manage 3+ wallets across multiple chains just to do basic stuff. And to make matters worse, apps are creating their own wallets and chains now.

All this fragmentation creates an increasingly confusing landscape for users, and makes the distribution and adoption of new onchain apps exponentially more challenging.

This is exactly the problem that we are solving through the Espra Crypto Browser and the Espra Hyperchain.

Espra Crypto Browser

The Mismatch Between Web & Crypto

The very first attempt at a crypto browser, Mist, gave us many wonderful things like Web3.js and ERC-20. But it also made a fatal mistake [Van19]. It was built on top of a traditional Web browser.

The Web’s security model was built for documents and is based around domain names. In contrast, crypto’s security model is based around user accounts and smart contracts.

The two models just don’t fit. If a single website gets hacked, just the data you had on there gets compromised. But, if a single dapp gets hacked, you might lose funds across all dapps.

Wallet extensions like MetaMask and browsers like Brave provide the semblance of compatibility. We can do better — create a crypto-native browser built around crypto’s unique security model.

And that’s Espra. A native app that users can install on Windows, macOS, iOS, Android, and Linux — just like Chrome. But built from the ground up to be 100% crypto native.

Keeping the Best Parts of the Web

Espra keeps just 4 things from the Web:

JavaScript:
- Our onchain scripting language will feel very familiar to JavaScript/TypeScript developers.
- This gives us access to the world’s largest developer community. Over 12M developers — hundreds of times larger than the entire crypto developer base!
- Building apps on Espra will be just like building apps using React Native. Here’s roughly what “Hello World” will look like on Espra:
```
import { Text } from "espra/ui"

let count = 0

function incrCount() {
  count += 1
}

export class App {
  render() {
    return <Text onclick={incrCount}>{`Hello world! Clicks: ${count}`}</Text>
  }
}
```
WebGPU:
- This gives us direct access to the GPU across desktop and mobile platforms. We build on this to create a reactive rendering layer for onchain apps.
- Thanks to WebGPU’s consistent API across different devices, app builders can use it to create high-performance 3D graphics, slick animations, simulations, etc.
- Since GPUs are a key component of AI, we can even run AI models locally, e.g. this demonstrates Meta’s Llama 3.2 model running locally on top of WebGPU.
WASM (WebAssembly):
- This lets developers write in languages like Rust, Zig, or even C++ for performance-sensitive parts of their apps, e.g. cryptographic operations, video encoding, etc.
Links:
- Hyperlinks are the primary UX innovation that made the web such a success. We retain the benefits of links, but without the limitations of URLs.
- Instead of HTML links where you have to encode data into URL strings:
```
<a href="https://example.com/search?some=value">Web</a>
```
  Our links let you pass structured data to apps, including things like onchain assets and authorizations:
```
<Link app={search} data={{some: "value"}}>Espra</Link>
```
- Both onchain apps and content can be referenced in these links via content-addressed references on Espra’s distributed storage layer.

We abandon everything else from the Web:

No domain names. No cookies. No HTML. No CSS. No SVG. No WebRTC. No HTTP. No URLs.

By keeping just the useful parts and throwing away the rest, we are able to create a simpler foundation that’s purpose-built for onchain apps and crypto’s security model.

Onchain UI: A Crypto-Native Interface Layer

Apps built on Espra are truly decentralized. From the frontend to the backend, every component is fully onchain. Builders publish apps to the Espra Hyperchain with a simple manifest:

This defines the basic metadata, e.g. app name, description, icon, etc.
It lists the minimum version of the Espra SDK that the app requires, as well as the versions of any onchain dependencies.
It states whether the app should be always running in the background. This would allow the app to listen out for changes and act as an autonomous agent for users.

The manifest, along with the app’s source code and assets like images, are uploaded to Espra’s distributed storage system. The app can then be accessed via an Espra link, e.g.

# Content-addressed reference.
9fee1dbeef70b5e7ebde3b2e923325d5d6d6e898e74349521eba6c98d2c7b5ec

# Versioned tilde reference.
~1.tav/hello-world-app@2024-10-30

Unlike dapps today which rely on Web2 infrastructure for their interface, these apps are fully onchain:

They won’t go down because some random website went down, or because the app creators failed to raise the next round of funding.
Once published, apps are fully immutable. They can’t get hacked or replaced with a malicious version. Thanks to version pinning, they’re even immune to supply-chain attacks.

Developers can publish libraries and components onchain, allowing others to easily build on top, e.g. here is James’s Select component being used by someone else’s app:

import { Select, SelectItem } from "~23.james/component/select@2024-10-31"

export class App {
  render() {
    return (
      <Select>
        <SelectItem value={1}>One</SelectItem>
        <SelectItem value={2}>Two</SelectItem>
      </Select>
    )
  }
}

Everything is fully versioned. An app that worked yesterday won’t suddenly stop working. Security audits can be faster as they can skip over previously audited versions of dependencies.

Unlike with Web apps where your data is stored on someone else’s servers, everything on Espra except for onchain data is stored on your own device.

This gives users greater control over their own data and more privacy.
There are fewer moving parts. No need to worry about Web2 infrastructure, domain names, setting up databases, etc.
Once loaded, all apps work fully offline. No extra work needs to be done by app developers. Users only need to go online to transact, or sync with the latest onchain data.
This local-first approach makes building apps more natural and easier to reason about.

The local data system can be used to store structured data including onchain assets. This system, along with our ChainState API, can be queried — even for real-time changes:

import { liveQuery } from "espra/chainstate"

const result = await liveQuery(`
  select DEXPrice {
    timestamp,
    price
  } filter
    .base_currency = SOL and
    .quote_currency = USDC
`)

result.onChange(result => {
  // Display price changes in the UI.
})

We build on Expo from the React Native ecosystem to provide a cross-platform API for accessing device-specific capabilities like the camera, accelerometer, etc.

import { CameraView } from "espra/camera"
import { Text } from "espra/ui"

export class App {
  render() {
    return (
      <CameraView facing="front" mode="picture">
        <Text>Take a selfie!</Text>
      </CameraView>
    )
  }
}

All of this makes it easier to build apps on Espra than on most platforms today. And thanks to the Espra Hyperchain, these apps can interact with every chain that we integrate with.

Actions: A Simpler UX for Signing Transactions

Signing transactions is a core part of interacting with onchain apps. But it’s also scary for most users:

What am I signing?
Has this contract been audited?
Did I type the address correctly?

Technical users might be able to look at the transaction payload and see what it’s doing, e.g. it’s calling the swap method on a specific smart contract:

swap(amount0Out, amount1Out, to, data)

Even then, they won’t know for sure that the swap call won’t do something unexpected without looking at the contract code itself. All of this can be pretty intimidating.

Espra introduces an alternative approach that we call Actions. These focus on the heart of the user’s intent, e.g.

Send some money.
Swap some assets.
Book a taxi.
Order some food.
Borrow some money.

These are defined on an Action Registry on the Espra Hyperchain, e.g. “Book Taxi” might look like:

{
  name: "Book Taxi",
  parameters: [
    {
      field: "route",
      type: Route,
      sub_fields: [
        {
          field: "pickup_location",
          type: GeoLocation,
        },
        {
          field: "dropoff_location",
          type: GeoLocation,
        },
      ],
    },
    {
      field: "driver",
      type: Person<Driver>,
    },
    {
      field: "estimated_cost",
      type: Asset,
    },
  ]
}

The first time a user encounters an Action, we will use it as an excuse to explain what it does. A bit like how the Pokédex tells you about new Pokémon you’ve caught.

Each Action can have a set of parameters, e.g. the amount of money to send, the recipient address, the route for the taxi, which assets are being swapped, etc.

These are displayed to the user in an easy-to-understand manner, e.g.

Displaying an existing contact’s name and profile image instead of their wallet address.
Displaying a route on a map instead of just displaying the coordinates.

Builders will map their onchain transactions to Actions via Transaction Mappings, e.g. a new ride sharing app might define this mapping:

{
  action: "Book Taxi",
  chain: ethereum.mainnet,
  contract: "0xabcdef",
  method: "confirmRideByPassenger",
  parameters: [
    {
      action_parameter: "driver",
      name: "driverAddress",
      type: address,
    },
    {
      action_parameter: "estimated_cost<ETH>",
      name: "price",
      type: uint256,
    },
    {
      action_parameter: "route.pickup_location.latitude",
      name: "startLatitude",
      type: uint256,
    },
    {
      action_parameter: "route.pickup_location.longitude",
      name: "startLongitude",
      type: uint256,
    },
    {
      action_parameter: "route.dropoff_location.latitude",
      name: "endLatitude",
      type: uint256,
    },
    {
      action_parameter: "route.dropoff_location.longitude",
      name: "endLongitude",
      type: uint256,
    },
    {
      name: "vehicleType",
      type: uint8,
    }
  ]
}

Instead of constructing onchain transactions directly, apps construct them through these Transaction Mappings — establishing a clear relationship to the intended user Action.

In addition, when we present the Action to the user for them to authorize, we use their Trust Map, i.e. our built-in reputation system, to determine whether:

The Transaction Mapping is valid.
The current version of the smart contract has been audited.

Actions allow us to abstract away the technical details of onchain transactions. Instead of gobbledegook, we can present users with something simple that they can understand.

On top, thanks to Trust Maps, we can help provide a safer environment for users. This also provides developers with a structured way to build trust-aware apps.

Thus we transform one of crypto’s biggest UX challenges into an opportunity for creating more intuitive and secure onchain experiences.

Browser Security Considerations

Espra builds on the security model from E, the very first distributed smart contract system — Object Capabilities. This is used to:

Share access between apps in a composable manner while preventing unintended leaking of access.
Prevent privilege escalation attacks that are common in traditional access-control list-based systems, e.g. the confused deputy problem.

In addition, we make use of sandboxing where possible and pay attention to potential side channels, e.g. using the new V8 Sandbox while executing JavaScript, leveraging WASM’s sandboxing, etc.

The core of the Espra Browser is written in Rust, which provides us with better memory safety guarantees than languages like C/C++, while still being performant.

Our main area of concern is the GPU. While WebGPU has been enabled on browsers like Chrome, GPU drivers are notoriously buggy. To counter this, we will:

Create an audit process for all WebGPU code. Apps using unaudited WebGPU code will be automatically disabled on devices with GPU drivers that are known to be buggy.
Proactively add new layers of validation to WGSL, the WebGPU Shading Language, to prevent invalid operations from being sent to the GPU in the first place.

Espra Hyperchain

There have been many attempts to create a unified layer across different chains, e.g. Cosmos IBC, Polkadot Parachains, Avalanche Subnets, LayerZero, OP Superchain, etc.

But they all suffer from issues. Some impose too much structure on how constituent chains should behave. Some can only be used for certain use cases.

With the Espra Hyperchain, we take a radically different approach:

We provide a single, universal API for reading and indexing onchain data that can be applied to all chains. This is our ChainState API.
We layer a workflow engine on top of this, our Activity Engine, that lets apps orchestrate complex workflows across multiple chains.

The Espra Hyperchain is just a coordination layer that can be leveraged by apps built on Espra. There’s no cross-chain messaging, no bridges, no need to share sequencers, etc.

Chains are Just State Machines

While each chain has its own distinct RPC API, they are all just state machines at their core. Transactions simply cause changes in this underlying state.

For example, the internal state of a smart contract might initially look like:

{
  contract: 0xabcdef,
  memory_slots: {
    0: true,
    1: {
      0x123: 500,
      0x456: 20
    }
  }
}

A transaction might cause this to become:

{
  contract: 0xabcdef,
  memory_slots: {
    0: true,
    1: {
      0x123: 450,
      0x456: 20,
      0x789: 50
    }
  }
}

The raw state changes caused by the transaction could be described with:

[
  {position: "0xabcdef/1/0x123", previous: 500, value: 450},
  {position: "0xabcdef/1/0x789", previous: 0,   value: 50}
]

On its own, those changes might seem meaningless. But, when you translate them into semantically meaningful changes, you get:

The balance of account 0x123 has decreased by 50.
The balance of account 0x789 has increased by 50.

Or more concretely:

A transfer of 50 tokens of contract 0xabcdef took place from account 0x123 to account 0x789.

We can derive all that from just the raw state changes. No need for any events to be emitted by the smart contract, no need to make any specific RPC calls to the chain.

Since all chains track their state changes, we can use this to provide developers a single interface for reading — both current and historic — onchain data from every single chain.

ChainState: A Universal API for All Chains

For each chain that we integrate via ChainState, we implement the following components:

Raw Indexer:
- This emits the metadata for each onchain transaction along with the corresponding raw state changes. This creates the “raw index” for that chain.
Broadcaster:
- This provides a standardized interface for broadcasting transactions to the chain.
Espra SDK Package:
- This adds a chain-specific package to the Espra SDK that can be used to construct transaction payloads, query the raw index, etc.

App developers can define their own State Translation functions that convert the raw state changes into Custom Indexes with semantically meaningful output, e.g.

import { onStateChange } from "espra/chainstate"
import { ETH, mainnet } from "espra/chain/ethereum"

// Register the State Translation function.
onStateChange({
  chain: mainnet,
  when: {
    contract: "0xfdecba",
    method: "delegate",
    slot: 3
  },
  // Example State Translation function.
  run: (metadata, changes, emit) => {
    for (const change of changes) {
      emit({
        account: metadata.sender,
        staked_amount: ETH(change.value)
      })
    }
  }
})

These can then be queried by apps, e.g.

Recent deposits to a specific user account.
Historic prices for a specific trading pair on a DEX.

The Espra Hyperchain maintains a list of all Custom Indexes that have been created, along with their corresponding State Translation functions — enabling developers to build on each other’s work.

We also provide an Aspect Registry that allows for gradual convergence of the schemas used within Custom Indexes. For example, instead of everyone defining their own fields:

An entry is added to the Aspect Registry, e.g. staked_amount<Asset> that is generic over the type of asset being staked.
This can then be reused by developers across multiple Custom Indexes — establishing a common, universal schema for related onchain data.

The query mechanism should be familiar to anyone who has used SQL. For example, to find all stake delegations for an amount greater than 8 ETH:

import { query } from "espra/chainstate"

const result = await query(`
  select StakeDelegation {
    account,
    staked_amount,
  } filter .staked_amount > 8.ETH
`)

// Result:
// [
//   { account: "0x123...", staked_amount: ETH("10.5") },
//   { account: "0x456...", staked_amount: ETH("12.0") }
// ]

Once the Espra Governance Token holders have voted to add support for a new chain, any Active Validator Node can choose to start running a ChainState node for it.

If an Active Validator Node doesn’t have the resources to run a ChainState node, e.g. for expensive chains like Solana, they can choose to delegate to others instead.

ChainState nodes must participate in staking for Proof-of-Stake chains, with the rewards split between those running the nodes, delegators, and Espra Governance Token holders.

Activity Engine: Going Beyond Individual Transactions

Real world use cases tend to involve multiple steps involving multiple parties. For example, ordering food for delivery involves:

Placing your order with an “escrowed” payment.
Having the restaurant confirm the order.
Waiting for the food to be prepared.
Assigning a driver for the delivery, and having it picked up from the restaurant.
Getting the food delivered to you.
Releasing the escrowed payment to the various parties.

Each of those steps could also fail in various ways. For example, the restaurant might not be able to fulfill the order, or the driver might not show up.

Such an app would be extremely complex to implement on most chains today as they only support individual transactions — dramatically limiting the kind of apps that can be built.

It would also be a UX nightmare. Users would need to keep an eye on each of those transactions, wait for them to succeed, and make sure to sign the transactions to get to the next stage.

We believe that it can be a lot simpler. Our core infrastructure includes Activity Engine, a workflow engine for orchestrating onchain transactions. Each step of a workflow defines:

What conditions constitute success in terms of authorizations or ChainState queries, e.g. a transfer has succeeded, the restaurant has confirmed the order, etc.
What to do on success, e.g. perhaps a follow-on transaction is needed to release the escrowed payment, etc.
What to do on failure, e.g. refund the escrowed payment, retry a failed step, etc.

Each step can branch into multiple parallel steps, e.g. the restaurant might start preparing the food while the driver starts heading to the restaurant.

Each step can also refer to output from previous steps, e.g. the driver might need an order number that was created when the restaurant first accepted the order.

Steps can span multiple chains, e.g. the restaurant might be on Ethereum, the driver on Solana, and the payment on Avalanche. The Activity Engine is chain agnostic.

Steps can even wait on offchain events and require additional levels of authorization. All of this allows Espra to support the full range of complexity faced by real world use cases.

Network-Owned Accounts: Enabling Cross-Chain Transfers

Instead of using insecure bridges to transfer funds between other chains and Espra, we make use of Network-Owned Accounts, i.e. accounts on other chains that are controlled by the Espra network.

These Network-Owned Accounts are just normal accounts on these other chains, and thus can do anything a normal account can do on that chain.

The only difference is that the private key for the account is generated through DKG (Distributed Key Generation) by active Validator Nodes on Espra.

People can make deposits to these addresses just like they would normally. ChainState would be used to detect these deposits and mint a mirrored asset on Espra.

In concrete terms, if Alice wants to receive some ETH from Ethereum:

She would create a deposit address for Ethereum. Behind the scenes, this would create a Network-Owned Account on Espra for an Ethereum address.
She would give the deposit address to the person sending the ETH, and wait for the transfer.
ChainState would detect a deposit of 4 ETH to the address and mint a corresponding asset on Espra.
Alice can now transfer this asset on Espra just like any other asset.

Withdrawals simply work in the opposite direction. Alice can withdraw her ETH to any Ethereum address of her choice. All this without worrying about bridges:

No need to trust a bridge with your funds.
There’s no single point of failure.
No need to be limited by the bridge’s capabilities, e.g. if the bridge doesn’t support the token you want to transfer.

Network-Owned Accounts make it easy to transfer funds between Espra and other chains, and enable other powerful features such as Sponsored Transactions and Network-Owned Liquidity Pools.

Key Mechanisms

Espra Hosts: A Hybrid P2P/Cloud Network Architecture

Most decentralized networks are built around the traditional P2P (Peer-to-Peer) architecture, i.e. where all nodes are equivalent and each node can act as a server for any user.

This has repeatedly proven to be a poor architecture:

Most people aren’t incentivized to run their own nodes as it’s too expensive. As a result, the network tends towards centralizing around a few large providers.
Public nodes are often vulnerable to attacks and are difficult to secure. This makes it difficult for users to trust the nodes they’re connecting to.
Apps often need functionality beyond just reading blocks and submitting transactions, e.g. indexing, running persistent queries, storing arbitrary content, etc.

Espra takes an alternative approach where each user is “housed” at a particular Espra Host, which:

Runs its own Validator Nodes to participate in consensus.
- Validator Nodes start out as Candidate Validators and only become Active Validators once they receive enough validation power.
- Candidate Validators proxy transactions from their users via an Active Validator that they have registered with.
- Active Validators only include transactions from users housed at that Host, or from Candidate Validators that have registered with them.
- The Active Validators form a latency-optimized mesh network, with a hierarchical relationship to Candidate Validators.
Runs a set of Service Nodes that provides a set of standardized services to users housed at the Host:
- Activity Engine: A workflow engine for orchestrating transactions across different chains based on ChainState.
- BlobStore: A distributed storage system for arbitrary content.
- ChainState: A universal API for reading and indexing onchain data from other chains.
- Dial: A way to connect users directly to each other. This service can also be called by other Hosts who want to connect to a user on the receiving Host.
- Keychain: A secure vault for storing cryptographic keys.
- Live Query: A continuous querying system for ChainState data. This uses our novel pattern-matching mechanism for fast and efficient querying without polling.
- Offchain Compute: A framework for running arbitrary offchain computation through a sandboxed WASM (WebAssembly) runtime.
- Trace: A standardized mechanism for users to track the progress of any API calls they’ve made, any associated logs, etc.
- UserStore: A BlobStore for storing arbitrary content that can only be accessed by the user themselves.

Users run a thin client that interacts with the rest of the network via their Espra Host. This is automatically done by the Espra Browser on the user’s behalf.

For use cases like transferring files from one user to another, it could be done directly between 2 users after an initial connection is established using the Dial service.

Hosts can offer these services for free, or charge for them. Users can change their Host whenever they want, with a small cooling down period (e.g. 2 hours) to minimize resource exhaustion attacks.

Our hybrid P2P/cloud architecture lets us take advantage of the best of both worlds:

The P2P layer keeps the network open and permissionless.
The cloud layer lets us provide a much better experience than a pure P2P system for users and app builders.

Users can move to a Host with better security, reliability, and performance whenever they want. Or even run their own Host.

Onchain Scripting: Code Execution via JavaScript

While we don’t provide full-blown smart contracts, Espra supports the execution of arbitrary code via Onchain Scripts to:

Implement custom workflows.
Implement custom logic for Espra-native apps.
Maintain a registry on Espra.

This is intended to complement the smart contract capabilities of other chains, e.g. to implement custom workflows that aren’t natively supported on a particular chain.

The Scripts are run within the Espra WebAssembly runtime, a fork of WASM (WebAssembly) with additional support for deterministic and gas-metered execution.

The runtime will initially support the execution of JavaScript and TypeScript, and may be extended to other languages in the future if the maintenance burden is worthwhile.

Onchain Scripts are executed within the context of a particular Space, i.e. a collection of data and code that can be shared between a collection of Onchain Scripts.

Unlike smart contract platforms where contracts can call arbitrary methods on each other within the same transaction, Onchain Scripts cannot mutate state outside of their own Space.

Each Space has its own “inbox” and “outbox”. A transaction on Espra is effectively just a message that is being placed in the inbox of a specific Space.

Separate transactions must be used to transfer resources from one Space to another, and the signer must be authorized to move specific resources.

These transferable resources must be of a predefined Transferable Type that’s been registered on Espra. These function as a sort of custom UTXO asset.

This message-passing nature of Espra Spaces gives us incredible horizontal scalability, as users only execute transactions in the Spaces that they care about.

Identity & Security

MultiSec: Fully Programmable Account Security

Espra accounts are fully programmable, allowing for arbitrary workflows to be implemented. It is based on a few basic primitives:

Device Keys: Cryptographic keys of specific “security levels” stored on physical or virtual devices, e.g. smartphone, laptop, security key, etc.
Security Policies: A set of rules used to authorize actions, e.g. transfers might require a “high security” key with co-signers, while a “low security” key would do for an onchain blog post.
Account Scripts: Onchain Scripts with custom logic, e.g. create approval chains for organizational accounts, enable automated security responses to suspicious activities, etc.

There will be a few built-in security policies:

Transfer Limits: Require co-signers for transfers over certain amounts within a certain period.
Account Recovery: Allow for the account to be recovered by a set of authorized signers in case all of the user’s device keys are lost.

Co-signers could be other devices owned by the user, other users, or even third-party custody services such as those provided by companies like Coinbase or Gemini.

For example, an account might use:

Low security: Blog posts, social interactions, require just a single device key.
Medium security: Small transfers less than $1000, requires 2 device keys including one “high security” key.
High security: Large transfers over $1000, require 2 “high security” device keys + 1 external co-signer.

Our MultiSec framework is flexible enough to give power users complete control, while letting average users have a secure out-of-the-box experience without worrying about key management.

For example, private keys for accounts on other chains will be stored using MPC (Multi-Party Computation) across the user’s devices and their Espra Host for easy recovery if devices are lost.

We use social vouching, i.e. getting users to vouch for each other, as a built-in mechanism to verify users as real people:

Vouching is bi-directional, i.e. if A vouches for B, then B vouches for A. This creates mutual accountability.
Users can initially vouch for up to 20 other users. This limit may increase based on the user’s reputation and time in the network.
Vouched relationships have a 30-day cooldown period to prevent network manipulation by rapidly changing vouched relationships.

A network flow algorithm, starting from trusted seed nodes, is used to determine the “verification” score of each user. Those within the top N% are considered as Verified Users.

The exact cutoff point for N will change over time as the network grows and will be influenced by the levels of fraudulent activity.
The use of network flow limits the damage that can be done by malicious actors vouching for each other, as they will have a limited amount of flow to distribute.

Since fraudulent activity tends to be localized to sub-graphs of social networks, this helps to easily detect and isolate fraudulent activity within the broader network.

By baking this reasonably palatable “proof of human” into the core of Espra, app builders can focus on building great apps without worrying about bots or fake accounts.

Trust Maps: A Reputation Layer for the Trustless Ecosystem

Espra lets users define contextual Trust Maps, e.g. a user “Ken” might trust:

Alice, Angus, and Stefan for #defi.
Max and Vitalik for #contract-security.

Apps can leverage this as a subjective reputation system, e.g. to determine the reputation of something, or even to choose specific sources to query for certain data.

By adding someone to your Trust Map, you can also benefit from those that they have added for the same context, e.g. Angus might trust James and Ben for #defi.

The Espra Browser will use a user’s Trust Map for the #contract-security context to decide on whether signing a transaction with a particular smart contract call should be considered safe or not.

This subjective mechanism will help protect users from malicious contracts while letting knowledge of contract audits spread organically through the network.

Over time, we expect this mechanism to help users become more and more resilient to exploits and scams.

Network Economics

Espra Gas Tokens: Say Goodbye to Transaction Fees

We provide free Espra Gas Tokens ($EGAS) to all Verified Users on a regular schedule, e.g. every week. This lets them participate onchain without needing a native token to pay for transaction fees.

Onchain actions on Espra will cost different amounts of $EGAS depending on the resources they require, e.g. a cross-chain action with 20 steps will cost a lot more than a simple transfer.

$EGAS tokens expire after a certain period, e.g. 3 months, so as to prevent people from hoarding them indefinitely. Users can sell any excess $EGAS tokens on the built-in exchange.

Espra Hosts will also be issued $EGAS tokens for each Verified User signed up to them. They can use these to subsidize new users, or to recoup any costs by selling the tokens.

While the Espra Governance Token holders will decide on the exact amount of $EGAS minted and distributed during each period, our initial thinking is to:

Let the previous period’s usage inform the next period’s distribution.
Provide enough $EGAS to each user so that it covers at least 68%, i.e. 1 standard deviation from the mean, of expected usage in the network.

Thus, the amount minted will go up and down in sync with the level of onchain activity on Espra, and the majority of users would always have enough $EGAS to cover their needs.

For those needing a bit more, e.g. someone running a high-frequency trading bot, they can always buy additional $EGAS tokens on the built-in exchange.

Appreciation: An Experimental Reward Mechanism for App Builders

Building great apps is hard. It takes a lot of time and effort. In order to reward the app builders, we’ve come up with an experimental token mechanism called Appreciation.

The Espra Browser will automatically keep track of all apps used by a user, and at the end of every cycle, e.g. monthly, will prompt the user to distribute their Appreciation for that cycle to the app builders.

Unlike say donations or tips, it won’t cost users anything to distribute Appreciation to others. It also won’t take anything away from them. Thus we believe this has a strong chance of success.

To prevent gaming by bots, the issuing of Appreciation will be limited to Verified Users, and if within a certain time (e.g. a week), a user hasn’t distributed their Appreciation, it’ll be done automatically.

The Appreciation received by the app builders will be a soul-bound token [OWB22], i.e. it will not be transferable, and will represent a percentage of the total Appreciation distributed in that cycle.

The relative amount of Appreciation received by app builders will then be used to mint an Espra native stablecoin ($PECU) that can be used in the rest of the network.

Thus we hope to create a virtuous cycle where app builders get rewarded for building great apps, which in turn drives more users to the platform.

Distributed Architecture

Kairos: Scaling to Millions of Transactions per Second

Our consensus mechanism, Kairos, is able to sequence transactions at record-breaking speeds of millions of transactions per second. This is thanks to:

Letting Validator Nodes produce blocks in parallel. This removes the latency overhead of coordinating block production.
Focusing on just sequencing transactions, and not executing them like most chains. This avoids the need to spin up the expensive execution machinery or do extensive state lookups.

Kairos is byzantine fault-tolerant as long as the network size exceeds 3f + 2 nodes. That is, if there are f faulty or malicious nodes in the network, there need to be at least 2f + 2 honest nodes.

Unlike consensus mechanisms like Ethereum’s Gasper [BHK+20], which alternatingly sacrifices either safety or liveness and allows for network splits, Kairos prioritizes safety over liveness.

At every tick interval, each Validator Node can produce a block for that tick containing any submitted transactions from the users of the corresponding Espra Host.

Each block includes references to blocks produced by other nodes in previous ticks. If a block is referenced by at least 2f + 2 other nodes within a commit_window of n ticks, it will be committed to the chain.

Fig. 1

DAG (Directed Acyclic Graph) of Blocks Produced by Validators

For Espra, we’re thinking of using a tick of 250 milliseconds and a commit_window of 8 ticks, giving us finality in less than 2 seconds.

If we limit the active validator set to 10,000 nodes and the candidate set to 1,000,000 nodes, we get an upper bound of 8 million transactions per second on today’s hardware.

We can adjust these parameters as necessary, but believe this is a decent-enough starting point for the Espra Hyperchain.

Diffusion: Ensuring the Network Stays Open and Decentralized

To protect themselves from being overrun by malicious nodes, i.e. for sybil resistance, most chains tend to use either PoW (Proof-of-Work) or PoS (Proof-of-Stake).

These mechanisms have tended to create a lot of centralization, e.g. just 5 entities (Lido, Coinbase, Binance, ether.fi, and Kiln) control over 50% of the current validators on Ethereum.

To avoid this issue, Espra uses a novel mechanism called Diffusion where the Validator Nodes of each Espra Host keeps track of the performance of other Hosts and their Validator Nodes across:

Technical Metrics:
- Availability, i.e. how often is a node available to serve requests.
- Reliability, e.g. does the node reliably share with others the data that it’s been previously given.
- Physical Distance, i.e. how far away is the node physically as determined by latency-based network positioning.
Economic Metrics:
- Objective Value Weight, e.g. how much time-weighted money flows to users on a particular Host from the ranking Host’s users?
- Subjective Value Weight, e.g. how much relative Appreciation do users on a particular Host receive from the ranking Host’s users?

Each Espra Host publishes this ranking of other Hosts periodically, and a certain portion of its validation power will then “diffuse” to these other Hosts based on their ranking.

This enables the network to gradually become more and more decentralized over time, while being dynamic to network changes and rewarding value generation.

The public nature of the ranking also allows Hosts to detect and punish those colluding against them by reducing their future rankings in a game theoretic tit-for-tat manner.

BlobStore: Enabling Exascale Content Storage

Instead of adding a secondary system like Arweave or IPFS/Filecoin, Espra provides native support for content storage onchain via our BlobStore.

Nodes for this subsystem are run as part of each Espra Host. They provide support for reading and writing two types of files:

Static Blobs, e.g. app code, images, videos, etc.
- These are content-addressed, i.e. referenced by the hash of their contents.
Appendable Blobs, e.g. indexes, series of tweets, etc.
- These are uniquely identified by a GUID and version number.
- They are append-only, i.e. new records can be added to the end of the file, but existing records cannot be modified.
- They are implemented as verifiable data structures, allowing for efficient random access and syncing between nodes.

We do not support mutation of existing records, as that would introduce a lot of potential failure scenarios — making safe syncing between nodes difficult and hindering the ability to scale.

Only a single writer will be authorized to create or update a particular blob at any given time. This is managed through leases obtained via consensus that establish exclusive access for a limited time.

Users create blobs indirectly through apps, which in turn use the user’s Host to coordinate the creation of the blob across a distributed set of BlobStore Nodes — the Replica Set.

Any trusted peers of the Host, along with a deterministic algorithm based on availability data and intended content, are used to derive the specific Replica Set for each blob.

The exact number of replicas in each Replica Set will vary with time based on the expected availability and node failure rates:

For example, if BlobStore Nodes typically have a 12% chance of failing every year, and we wanted 99.9999% availability, we’d need to have 7 replicas.

Hosts help to keep other Hosts honest through periodic data availability sampling of the content stored on their BlobStore Nodes. This helps to avoid bitrot as well as catch malicious nodes.

Failing nodes will be given a grace period before being removed from Replica Sets. This will minimize any unnecessary churn caused by transient issues or denial of service attacks.

Organization & Governance

Espra TON: The Organization Building the Espra Platform

We’re using a merit-based organizational structure called TON (Trust-based Open Network) that lets us attract and retain highly-talented contributors whilst remaining focused and agile.

The Espra TON is responsible for:

Leading the open source development of Espra.
Operating the first Espra Host, the initial Validator Nodes, and initial ChainState Nodes.
Managing various community efforts, e.g. hackathons, events, ecosystem investments, etc.

Espra TON is structured as a network of trust, where members earn their position by building up a history of positive contributions to the project.

Unlike DAOs, which are structured as simple token-weighted voting mechanisms, TONs are centered around trust relationships which we believe to be essential for collaboration.

All members of Espra TON start out as “open members” who can freely join and leave the organization. By earning the trust of others, they can gradually become “backed members”.

Backed members can draw down a “base pay” proportionate to the value they bring, as well as vote in various decisions like the allocation of resources.

By letting membership be open, and be earned rather than bought, we’re able to build a network of people who truly share our values and vision, as well as minimize the cost of recruitment.

The allocation of resources, beyond base pay, is split into two pools:

The “Central Pool” which is distributed “top-down” starting with the President of Espra TON — initially our founder.
A “Community Pool” which is distributed “bottom-up” by the backed members.

This way, we can ensure that Espra TON can head in a specific direction based on the vision of the top members, while also supporting intelligence at the edges.

All votes will be transparent and public within a “one person, one vote” system. Votes can be vetoed by the President, but this can be overturned by a supermajority (e.g. 66%).

Any disputes between members will first be handled through open discussion. If that fails, it can be escalated to a dynamically allocated adjudicator, potentially resulting in a ban from Espra TON.

Unless we find a better alternative, we’re currently considering using the LLP (Limited Liability Partnership) structure from the UK as the legal entity for Espra TON.

LLPs are a well-established, tax-transparent, UK legal structure that can refer to a custom “member agreement”, i.e. it could defer to the Espra TON’s onchain contracts as the governing mechanism.

This could potentially provide us with a corporate entity that can be used to own real world assets and make legally binding agreements whilst keeping Espra TON governance onchain.

Espra Governance Tokens: Voting Rights and Distribution

Separate from Espra TON, the Espra Governance Token ($EGOV) holders help define the overall direction of the network. Specifically, the $EGOV holders vote on:

The release of new versions of Espra.
The exact parameters used by Espra Validator Nodes for consensus, i.e. Kairos and Diffusion.
The specific chains that will be integrated via ChainState. Token holders can use this to promote chains in which they are invested, as well as those that will bring the most value to Espra.
The specific onchain tokens/assets from other chains that will be mapped over as first class assets on Espra.
The parameters relating to Espra Gas Tokens ($EGAS), e.g. the amount that gets minted in any cycle, how quickly they expire, how they’re distributed, etc.
- During the initial vote, the current intent is to set the distribution to:
  - 35% to all Verified Users.
  - 35% to Espra Validator Nodes.
  - 10% to ChainState Node Operators.
  - 20% to $EGOV holders.
- And set the expiry to 3 months, with the number of tokens minted for Verified Users to be enough to cover 68% of activity.
The parameters relating to staking on ChainState nodes, and how staking rewards might be distributed — including potentially to $EGOV holders.
The parameters relating to the Network Fee on Sponsored Transactions, e.g. the fee amount, how it will get distributed, etc.
- During the initial vote, the current intent is to set the fee to a flat 20%, and distribute it evenly between $EGOV holders and Espra Validator Nodes.

Thus, $EGOV holders have a lot of power to shape the future of Espra and, depending on whether they vote to reward themselves, also get to benefit from the growth of the ecosystem.

The governance mechanism will operate through an Espra-native app that will let $EGOV holders vote on the above items:

New Proposals will need to go through active discussion for a period (e.g. 1 week) and reach a minimum quorum of backers (e.g. 2%) before it can become an Active Proposal.
- The active discussion period can be skipped for certain types of proposals, e.g. emergency updates for Espra releases.
Active Proposals will be open for a fixed duration (e.g. 1 week) for voting.
Some votes will only require a simple majority, while others will require a super majority (e.g. 66%) of all $EGOV holders.
Tokens cannot be sent to other accounts for a period (e.g. 1 week) after a vote is made, to prevent the system from being manipulated.

There will be a total of 1 billion $EGOV tokens, with the initial distribution as planned below. We reserve the right to update this based on community feedback:

8% for the founder and early team creating Espra 0.1.
10% for private sale in the seed round.
27% for Genesis members.
25% for contributors towards Espra 1.0.
30% for the Espra TON treasury for ecosystem investments, post 1.0 compensation, and other expenses.

The allocations for private sales, founder, and team will linearly vest every 3 months over 5 years — starting from the date of the Espra 0.1 release.

Roadmap & Vision

Genesis Journey: Launch Strategy and Roadmap

The release of Espra is divided into two phases:

Espra 0.1 — A minimal viable product enabling users to interact with foundational Espra-native apps.
Espra 1.0 — A production-ready platform integrating major chains, empowering builders to create apps that rival today’s web and mobile experiences.

We’re targeting a release of Espra 0.1 for early 2026, with the testnet going live a bit earlier in Q4 2025. The 0.1 release will have the following key deliverables:

An early version of the Espra Browser with cross-platform support for Windows, macOS, iOS, and Android.

Component Progress

Windows View ✅

macOS View ✅

iOS View 🚧

Android View 🚧

Rendering Layer 🚧

Execution Engine 🚧

Espra SDK 🚧
An early version of the Espra Host, deployable on standard Linux infrastructure.
Some Espra-native apps that help us validate the Espra SDK and demonstrate the capabilities of our onchain UI layer.

Component	Progress
Windows View	✅
macOS View	✅
iOS View	🚧
Android View	🚧
Rendering Layer	🚧
Execution Engine	🚧
Espra SDK	🚧

To take this to market, we will kick off a 5-year Genesis Journey, during which:

We will launch a community engagement campaign to bring together 100,000 Genesis Members, vested in Espra’s future, who will help shape its direction.
We will build around a vision of a Common Economic Protocol to empower creators — whether they’re app builders, content creators, or city builders.
We will work towards Espra 1.0 in the open, whilst running a series of events and hackathons that help builders get up to speed with creating apps on Espra.
We will actively engage with the different communities within crypto, integrate with them, and help onboard them — gradually solidifying Espra as the gateway to the whole ecosystem.

During this period, we will fundraise as necessary to support team growth, as well as list on centralized exchanges, whilst paying attention to any regulatory developments that might affect us.

As part of the development, we will make it easy to keep up with protocol changes on other chains, as well as track any performance and security issues they might have.

While we expect there to be initial resistance to switching away from existing wallets, we will help smooth this transition by providing a simple migration path for the popular wallets.

A key part of our development effort will also be on providing great documentation and developer tools. By bringing this all onchain, we believe we can iterate much faster than other alternatives.

At the end of the Genesis Journey, we are targeting:

A production-ready version of Espra 1.0.
Daily active users comparable to Ethereum this year, i.e. around 400,000 DAU.
Integrations with chains representing at least 50% of all onchain activity.
5,000+ developers actively building on Espra.

We believe this will set Espra up for long-term success as the defacto interface for the entire crypto ecosystem.

Future Directions

Espra opens up a number of opportunities that we might explore in the future:

As Espra takes off, we’ll most likely see deposits from other chains to network-owned Espra accounts. From experience with other systems, these assets tend to just “sit” there.

By putting these assets to work through low-risk yield-generating strategies like staking, we could derive additional revenue for those in our network and $EGOV holders.
We could implement gateways for traditional databases like PostgreSQL, MySQL, and MongoDB, that translate changes in those databases to ChainState changes within Espra.

This would make it easy to integrate Espra with existing “Web2” systems — without needing brittle lookups via oracles. After all, a lot of the world still runs on Excel.
By being the “app store” of the decentralized world, we would be in a good position to dramatically improve and rethink the UX around the discovery and launching of apps, e.g.
- Contextual launching of apps based on user behavior, trust map recommendations, and explicit preferences.
- Seamless app-to-app navigation enabled by our content-addressable linking.
We could make the user experience tighter by making the integration with the “offchain” world seamless, e.g. KYC, offramping, interacting with legacy payment rails, etc.

Instead of implementing these ourselves, we’ll work with established players to define open protocols that anyone can implement — creating a level playing field for everyone.

We see this as particularly important within emerging markets which haven’t yet seen a huge amount of standardization.
We could work with central banks to define a “Fiat Protocol” that lets users deposit fiat currency to accounts at the central bank and turn it into a stablecoin on Espra.

Since Espra acts as a neutral interface layer, central banks could participate without being seen as favoring any particular blockchain ecosystem, as all chains can integrate equally.
If the hardware for AR/VR ever becomes “good enough”, our direct GPU access puts us in a position to enable a lot of use cases, e.g. immersive education, interactions, games, etc.
While privacy-preserving cryptography has come a long way since the days of blinded signatures, there’s still no clear winner in this space.

If such a system were to emerge, our host-based architecture would put us in a good position to add support for it in a manner that is compliant with regulations around money laundering.
If our experiment with Appreciation is successful, we could potentially expand it beyond just app building, e.g. content creation, public service provision, etc.

In particular, by combining it with our “Attribution Twins”, we could potentially solve one of the biggest problems in AI — that of creating high-quality training data.
We could build GenUI, a prompt-based design tool to help create new onchain apps on Espra really easily. This could generate code based on existing onchain components.

At each step, we’ll look to align with the broader crypto ecosystem, and be guided by both our community as well as macro conditions within the tech space as a whole.

As new technologies emerge, we’ll be well-positioned to adapt and expand, always guided by our core mission of making crypto more accessible and useful for everyone.

References

BHK+20	Vitalik Buterin, Diego Hernandez, Thor Kamphefner, Khiem Pham, Zhi Qiao, Danny Ryan, Juhyeok Sin, Ying Wang, and Yan X. Zhang. Combining GHOST and Casper. 2020. External link
OWB22	Puja Ohlhaver, E. Glen Weyl, and Vitalik Buterin. Decentralized Society: Finding Web3's Soul. 2022. External link
Van19	Alex Van de Sande. Sunsetting Mist. Medium, 2019. External link

To cite:

@misc{tav2025espra,
  title={Espra: An Onchain UI Layer for the Multi-Chain Ecosystem},
  author={Tav},
  year={2025},
  primaryClass={cs.CR}
}