Epoch Protocol is an intent-centric abstraction layer that will sit between users, protocols, and chains and provably optimize for best conditions for all the involved steps, it will figure out the intent, find the best routes for desired actions, or wait for better routes, do intermediate steps like bridge funds if deficit, handle gas, make necessary swaps and ultimately execute user’s or protocol’s intention in a non-custodial way by leveraging SAFEs and ultimately also give a zk-proof of all the calculations.


With the advent of Rollups and multichain-verse, it's becoming more and more complex for users to do their desired tasks, funds are scattered across chains, gas is paid in different tokens and there are a lot of clicks, protocols, wait times, and chains involved.

On top of multiple networks, some intentions involve not just simple instantaneous execution but also waiting for better conditions, recurring tasks, and adapting to changing token balances.

All this in aggregation is not just a terrible user experience but also a key factor that prevents mass adoption of blockchains and more user-facing products from being built.


Epoch Protocol is an intent-centric network and abstraction layer, with pluggable observers, modular intent solvers, and advanced transaction bundlers that allows us to leverage ERC-4337 and SAFE, to completely abstract away chains and their complexities, and handle user intents in a non-custodial way even if they are supposed to be executed in the future.

Epoch Protocol has the following components to make it a scalable and user-friendly abstraction solution.

Epoch Node -

The node is divided into different environments -

Transaction Bundler

  1. This an ERC-4337 compliant bundler, with some extended capabilities.

  2. It has an alternate mempool and intent pool for transactions that are supposed to be executed on some specific conditions or when better conditions are found.

  3. It is a big wrapper around all the other components.

  4. It is connected to an App-chain to send intents and transactions to other nodes of the network.

  5. This also executes the final transaction when all the intent solvers have completed their work.

Context setter-

  1. If the user request is in the form of intent, the context setter breaks it down.

  2. It analyses the user requirements, context, triggers, and what needs to be optimized.

  3. It passes the trigger condition to the Observer and other transaction-related contexts to the Solver environment.

  4. This is a pluggable module, node operators have a choice of opting for a different context setter with alternate optimizations.

Observer -

  1. The observer environment has pluggable observers.

  2. Users and their intents can request a specific type of observer.

  3. The observer runs on each block, analyzes the chain state, sees if the user’s conditions are met, and ultimately marks the transaction or the intent to be ready to be sent.

  4. Observers have their storage state to maintain a state that may be needed for consequent calculations or analysis.

  5. Observers broadcast a zk proof to other nodes for its calculations and input params, other nodes verify the proof and see if the solution optimizes for the right conditions.

Solver Environment -

  1. This environment contains both Intent Solver Orchestrator as well as multiple modules.

  2. The Intent Solver Orchestrator ( ISO ) can connect to all the modules inside this environment and suggest the order in which each module should be called.

  3. A single module finds the best route for a single action ("Swap", "Stake", "Lend", etc).

  4. Multiple modules work together in the solver environment, as called by ISO to create a final aggregated route or solution.

  5. Finally, a complete solution is obtained and sent to the consensus layer.

Intent Solver Orchestrator (ISO) -

  1. ISO solves the steps that need to be involved (like bridging, swapping, staking, lending, etc.) for the intent.

  2. It also defines the sequence in which different modules should be called for solving a given problem.

  3. It can also query current market conditions such as gas cost, network congestion, etc. This helps ISO to select a sequence of modules that need to be called to provide a solution.

  4. Node runner can tweak ISO if they want or use their own algorithms to find out the sequence of modules.

Intent Module -

  1. There can be only a single module for each action and the purpose of a module is to find the best route for a single action like "Stake", "Swap", etc.

  2. A module can utilize different ways to find the best route including but not limited to plugging in multiple Intent Solvers, Adapter, using AI-based models, AI-generated Intent Solvers, 3rd party plugins/services, etc

  3. The module compares the result of each route and selects the one with the best output.

  4. Node runners can select which modules they want to plug in.


  1. Verifiable and weighted randomness is used to pick 5 nodes (for now, but can change later).

  2. The final solution from the solver environment is sent to the consensus layer, and other nodes do the same, 5 selected nodes verify all the calculations and proofs and pick the solution that either gives the best return or does the optimization best for what the user asked for.

  3. This environment also uses verifiable and weighted randomness to pick a node for finally executing the transaction.

  4. For all the comparisons and calculations this environment does, it generates a ZK proof for the verifiability of the calculations.

  5. All the nodes involved in consensus should reach the same outcome for a solution to be valid.

On-chain Contracts -

Epoch Protocol utilizes various contracts on the chain to give users more on-chain verifiability.

Registry and gatekeeper-

  1. This contract acts as a registry and verifies all the conditions that can be verified on the chain.

  2. Transaction data is added to this with a multi-send call when the transaction is being executed, it allows us to easily verify transaction conditions and maintain on-chain records without sending in multiple transactions for the same intent.

  3. This contract is a source of truth for hooks and plugins (discussed below).

  4. This contract also acts as an information store, it provides transactions that are supposed to be executed in the future with more context and data.

SAFE | Other smart wallets-

  1. This is a standard smart wallet.

  2. It maintains custody of the user fund.

  3. The user or owner(in the case of multisig) are the only signers, Epoch does not hold any signing keys.

  4. It helps execute and automate transactions without users giving custody of funds to Epoch Protocol.

Epoch Plugin

  1. Epoch plugin is an extension of Smart Wallet.

  2. This plugin provides transactions with extra information, pulling it from the Registry and Gatekeeper contract, which was unavailable during a transaction/intent signing.

  3. It prepares a complete transaction and sends it to the smart wallet for final execution.

Epoch Hook-

  1. This contract verifies the execution conditions.

  2. Two different checks can be made, pre-transaction and post-transaction.

  3. The hook contract gets information from the Registry and Gatekeeper contract and then verifies if all the conditions are being met.

  4. This provides additional on-chain security and verification.

Epoch Paymaster-

  1. Paymaster helps with paying gas fees on all the different networks.

  2. Users will not have to worry about having the right gas token on any network.

  3. It also helps with charging the users for transactions on one network where users do not have assets to pay gas on the other chain where users can pay the gas.

Epoch Liquidity Pools-

  1. Permissioned pools that maintain some working liquidity.

  2. There is one pool on each chain.

  3. It is used to bridge small amounts of funds instantaneously.

  4. Transaction will trigger user funds to be bridged to a specific chain towards this pool.

  5. While funds are being bridged to this pool, Epoch will use available liquidity to give users instant funds.

  6. This comes with a fee and is feasible only for transactions with smaller volumes.

Epoch SDK

  1. Epoch SDK is the primary component that dapp developers interact with to get various optimized transactions executed.

  2. Epoch SDK cuts down the time to intentify and automate transactions from days to just a few hours.

  3. It handles the signing, preparation of userOp, transaction, and intent.

  4. It signs all the conditions that must be satisfied for sending the transaction.

  5. It adds all the necessary calls to the userOp that will aid in on-chain verification, using multisend.

  6. It also allows developers to prepare userOp and transaction data to automate non-intent-based transactions.

All these moving components work together in stitching a solution that allows users and protocols to provide an unparalleled experience even for some web2 flows.

It also reduces efforts to build dApps by offloading extra work to Epoch Intent services.

Use cases

Some sample use cases


  1. DApps can be part of Epoch’s Intent solver repository and be part of various proposed solutions.

  2. DApps can get the user set with all the preliminary requirements for using their dApp, with just one click, something like getting the right tokens or positions, by using Epoch Protocol.

  3. Craft various strategies for investing tokens or earning APRs.

  4. DApps that need users to bridge funds from another network or simply swap tokens, can simply use epoch to get all the right transactions in place and if the amount is not big, give instantaneous funds to users using Epoch Liquidity Pool.


  1. Users can lend and stake based on changing on-chain conditions and APRs.

  2. Users will not have to care about their fragmented liquidity, they will be able to make transactions involving any tokens available on any chain.

  3. Instantaneous bridging of funds if the amount is low.

  4. Users will be able to tell their requirements in natural language.


Epoch Protocol would be a game changer in this multichain ever-changing web3 verse, fragmented liquidity, complicated actions to reach a goal, and understanding difficult transactions as Epoch Protocol will not only optimize for what the user has requested but also wait for better conditions, explore all the chains for better options and finally give a solution that will bring a lot of user clicks down to just two clicks and abstract away all the complexities.

Last updated