​
Future Directions

This section outlines various ideas for the future development of Routes. These are not guaranteed to be implemented, but are instead a guide for where the project is headed.

​
Batch Proofs for Native Route

Adding the ability to prove multiple intents in a single call would save around ~50% of the proof cost per proof. This is because the proveIntent function duplicates the proveAccount function call for each separate intent proof, and this call could be shared over multiple intents.

To drive the cost per intent down beyond the 50% threshold, optimizations to the storage layout of intents on the Inbox contract is required. This is a consequence of how hashmaps are laid out in Contract Storage in the EVM. As a reminder, the storage slot for a hashmap is calculated using the key and the base storage slot, as shown below:

storage_slot = keccak256(abi.encodePacked(key, base_slot))

// for example 
mapping(address => uint256) balances; // base key stored at slot 0
storage_slot_of_balance = keccak256(abi.encodePacked(address, 0))

As a result of the above, hashmaps in the EVM result in highly sparse Merkle Patricia Tries, as each key-value pair is stored in a unique location on the Trie and are often far apart from each other. This sparsity increases the size of storage proofs because each proof must traverse the tree independently, leaving little room for overlapping calldata. This results in higher costs for each proof as each proof carries its own data overhead. To optimize this, the proven intents could be saved in the Inbox contract using an array.

Arrays, unlike mappings, store their elements in contiguous storage slots. This means that once the base slot of the array is located, each element can be accessed by simply incrementing the index. Consequently, the Merkle Patricia Trie is much less sparse when arrays are used, as the elements are closely packed together.

This tighter packing of data allows for more efficient storage proofs since the paths to the array elements in the storage tree are more likely to overlap. By grouping intents into an array, the proof overhead is minimized as multiple intents can be proven with mostly shared calldata. By batching extremely large numbers of proofs together like this, the cost per proof can be driven down to near zero.

​
Off-chain Intent Publishing

As mentioned previously, intents can be published offchain and then funded onchain. Routes intents to support multiple offchain publishing mechanisms for solvers and users to coordinate intent fulfillment.

​
Optimistic Claims

Optimistic Claims would allow solvers to claim ownership of funds without a storage proof by providing a bond. The solver would optimistically designate a specific intent as fulfilled and then wait for a challenge period. If someone were to challenge, the challenger would post a storage proof showing a failure to fill, slashing the solver’s stake and giving it to the challenger.

This would dramatically reduce the cost of claiming intents, as the solver would not need to send a message from the destination chain to the origin chain. Instead, an optimistic prover can mark large batches of intents as fulfilled in a single call, saving on both gas and calldata.

​
Solver Reputation System

The protocol will implement enhancements to the Inbox Contract to incorporate a solver reputation system. This future feature aims to incentivize solvers to provide credible and timely quotes to users. By tracking onchain promises and their outcomes, the protocol will enable the evaluation of the solver’s fulfillment reliability, ensuring this reputation becomes a critical factor in user decision-making when selecting quotes — in effect, giving the Open Quoting System some teeth.

The mechanism would look something like this:

  1. Signature Agreement: A user and solver agree on terms (e.g., price, fulfillment timeline) via cryptographic signatures. Either party submits this agreement onchain, directly, or through a gasless relay with the signature of the agreement.

  2. Onchain Emit: Once submitted, the contract validates the agreement and emits an onchain event reflecting the commitment.

  3. Offchain Indexing: Offchain services index these emitted events to track solver commitments. Indexers calculate each solver’s fulfillment rate by comparing completed transactions against emitted promises.

  4. Fulfillment Scoring: The fulfillment score measures the percentage of agreements a solver successfully fulfills within the agreed timeline. This score is combined with price to rank quotes for users, ensuring both cost and reliability inform decision-making

These agreements can also be posted offchain somewhere similar to how intents can be posted offchain.

​
TEE Matching Mechanism

Lit Protocol, and other protocols like it, allow for trustless execution of programs running in trusted execution environments (TEEs) across a network of nodes. This opens an incredibly interesting opportunity to use these types of networks to match solvers and proposed intents in a decentralized manner. This is something definitely worth exploring.

If architected correctly, this could potentially remove the need for any intent management on chain, other than bidirectional transfer of assets. Using a USDC transfer on Lit as an example, the TEE matching mechanism would work something like this:

  1. An intent creator would signal desire to send USDC on Base by posting the intent to a Lit Program.

  2. Solvers would provide quotes with signatures to a Lit Program.

  3. The user would choose a quote, and co-sign it, and send it to the Lit Program. Lit would then: A) Use the user signature to transfer the reward to a pending claim contract on OP using Permit2. B) Execute the transfer of the USDC from the solver on Base using Permit2. C) If successful, do nothing. After a period of time, the rewards from step A become claimable. D) If not successful, claw back the funds in the pending claim contract to the user.

This would create a trustless method to match and execute intents conditionally across multiple blockchains without the need for multiple origination, fulfillment and proof transactions.

​
ZK-assisted Storage Proofs

In addition to the use of batch proofs into the prover contract, an incredibly effective tool to drive down the cost of trust-minimized storage proofs offchain are ZK assisted storage proofs. ZK-assisted storage proofs allow for an arbitrarily large number of storage slots to be proven with a single ZK proof. This means that thousands of proofs could be verified with only minimal amounts of call data.

For example, projects like Axiom and RISC-Zero allow for multiple storage slots to be proven with a single supplied world state root. In a world where this kind of system was integrated into the protocol, a single protocol participant could prove all intent fulfillments for a given root on a regular cadence.

For more information about how these systems work, please see this comprehensive article.

​
Polymer Prover

We are currently working on a Prover that will use Polymer to prove intent fulfillments. Polymer is a new proof system that will allow us to broadcast proofs of a given destination chain’s state to all origin chains that might want state from that destination chain. We intend to use a tree to store the individual chain proofs, and then broadcast the root of the tree to all origin chains.

​
Gas Efficiency

There are a number of ways to make the protocol more gas efficient, including batching intent proofs and claims, calldata compression contracts, and more. We will be exploring these options in the coming months.