We're excited to share the work we've been doing to make web3 feel more seamless for both users and developers. With Frame v0.6, we're introducing a set of new features that make it easier to operate across multiple chains simultaneously, while also improving the clarity of the actions you take on those chains. This release marks the first in a series of updates aimed at more aggressively pushing forward the web3 experience.

Introducing Omnichain

Omnichain is the new routing architecture in Frame v0.6 that eliminates the concept of "being on a chain." With Omnichain, dapps can route requests to any of the user's available chains as needed, enabling users to be "on" all of their chains at the same time. This simplifies the user experience and unlocks new possibilities for dapp developers to design truly multichain experiences that operate across chains in parallel.

Importantly, Omnichain is fully backwards compatible: dapps that use wallet_switchEthereumChain work with Omnichain and will already feel more streamlined out of the box. For legacy dapps that do not implement wallet_switchEthereumChain, users can still manually switch chains by using the chain selector in the companion extension. When switching chains, Omnichain only changes the chain for that particular dapp, leaving all of your other dapps on their respective chains. Additionally, Frame will remember this chain selection and automatically use it for that dapp in the future.

While these improvements are already a great step forward, Omnichain was designed to take things to a new level by giving dapps the ability to route to multiple chains in parallel – this is where the Omnichain request routing interface comes in.

First, with the user's permission, dapps can now request an array of available chains using the new wallet_getEthereumChains method. This gives dapps the ability to know which chains the user would like to use with their dapp. Then, dapps can route requests to any of those available chains using the new wallet_request method.

The wallet_request method allows dapps to provide additional request metadata to the wallet, such as which chain it should be routed to. This method is based on CAIP-27 (which Frame v0.6 also supports) with the main difference being that all of the parameters other than the request itself are completely optional. We really like this approach by the CAIP contributors, as it opens the door to a new design space for requests. We're excited to see how wallets can expand on and leverage this pattern.

Transaction Decoding

Another important feature that we've designed to work hand in hand with Omnichain is transaction decoding. By fetching verified contract ABIs and decoding the calldata of a transaction locally, we can reveal important details and provide greater transparency. The new transaction user experience is designed to dynamically reveal greater and greater insights about the underlying transaction. Local ABI decoding is just the beginning, and we have more exciting developments on the way to provide rich, easily consumable, and contextually informed summaries for every transaction, improving transparency and security for all users.

Push the Boundaries

At Frame Labs, we're dedicated to building a truly web3-native platform and delivering the best user experience, while always maintaining a strong focus on our core principles of privacy, security, and decentralization.

Frame is here to help you push the boundaries of web3, and we have many more exciting things planned for 2023. We can't wait to embark on your next adventure with you!

Start exploring with Frame v0.6:  https://frame.sh

Follow us on Twitter to stay up to date with our progress.

If you have any questions about v0.6, feel free to join our Discord!

Canary is a pre-release version of Frame that we're using to test new features before making them available to a wider audience. This is our first in a series of Frame releases aimed at more aggressively pushing forward the user experience in web3.

Over the past year at Frame Labs, we've spent a lot of time thinking about how to make web3 more seamless for both users and developers. One of the concepts we decided to tackle first is the idea of "being on a chain." Manually switching between chains is a relic from a single-chain paradigm, and it's time for chains to be accessible in parallel.

Built into Frame Canary is a new routing architecture called Omnichain. Designed to simplify the user experience, Omnichain eliminates the concept of "being on a chain" by allowing dapps to route requests to any of a user's available chains as needed. With Frame's Omnichain, users are now "on" all of their chains simultaneously. This makes operating across multiple chains seamless and gives dapp developers the ability to design truly multi-chain experiences, such as a decentralized exchange that allows users to swap tokens on mutiple chains at the same time.

We've also made sure that Omnichain is backwards compatible. Any dapp that currently implements the wallet_switchEthereumChain RPC method will work with Omnichain out of the box. If a dapp doesn't give you the option to switch chains natively, Frame now provides a network selector directly in the companion extension. Omnichain allows users to switch the chain for a single dapp without changing the chain for all of their other dapps. Frame will remember this selection and automatically use it for that dapp in the future.

These improvements are already a big step forward, but we're taking things to the next level with our Omnichain routing interface. This interface can be used by dapps that would benefit from talking to multiple chains simultaneously. With a user's permission, dapps can now request the array of available chains using our new RPC method, wallet_getEthereumChains. They can then route payloads to any of these chains by including a chainId in the JSON-RPC payload, such as "chainId": "0x1" for Mainnet or "chainId": "0xa" for Optimism.

On top of this, Canary brings with it a ton of other features, improvements, and fixes, including transaction decoding, which allows users to more easily view and understand the details of their transactions before signing them. Our goal is to provide a rich, easily consumable, and contextually-informed summary for every transaction to improve transparency and security. There's a lot more to unpack here, so stay tuned for an upcoming post where we’ll dive into more details and examples.

We look forward to helping our users push the boundaries of web3, and we have many more exciting things to come in 2023. We're dedicated to building a truly web3 native platform and delivering the best user experience, all while maintaining a strong focus on our core principles of privacy, security, and decentralization.

Start exploring Frame Canary today!

Download: https://github.com/frame-labs/frame-canary/releases/latest

Follow us on Twitter to stay up to date! @0xFrame

The first thing you’ll notice is this launches a new window within Frame. This was a very conscious choice and we’re planning a series of posts to both explain the rationale for this and expand on our vision for the future of Frame. For now the main thing to understand is that to send assets in Frame... you still need a dapp! The only difference is that this dapp was written by the Frame Labs team and comes bundled with the application.

How to Use It

The dapp itself is simple and hopefully intuitive enough that most of the features don’t warrant an explanation, but let’s go over some of finer points that may be less obvious:

1. First you’ll notice that the “chain selection” control, nearly ubiquitous in dapps, is gone! That's because this dapp works on all chains that you’re connected to at the same time. There's no need to select a chain, switch chains or even the concept of being “on a chain” at all — everything is in one place.
2. When you first open the dapp, you’ll see a list of all of your assets — that is, the native currencies of all of the chains you’re connected to as well as any ERC-20 tokens on those chains. These assets are based on the token lists used by Frame and any custom tokens you’ve chosen to track. Use the search filter to quickly filter assets by name, symbol or chain.
3. You can navigate using only your keyboard. Use Enter to submit any information, ↑ / ↓ to scroll the list of  tokens and Ctrl + ← / → (Win/Linux) or Command + ← / → (macOS) to navigate through panels. If you prefer using the mouse you can also navigate using the buttons at the bottom-right corner of the window.
4. Once you submit you will be able to change gas settings or look at contract data in Frame just the same as with any other transaction.

A Parallel Chain Experience

We wanted to use this opportunity not only to deliver an oft-requested feature but to offer some fresh ideas for how to address some of the UX issues that we see in the current web3 landscape.

Specifically — and most relevant to this post — is the fact that today most decentralized applications maintain the concept of being "on a chain". In order to interact with different chains, the user needs to switch back and forth and is sometimes prompted to do so repeatedly to accomplish basic tasks. This experience is tedious, annoying and rapidly making less and less sense in an environment with an expanding web of interconnected sidechains and Layer 2 solutions.

Chain routing in Frame!

To remedy this, we added infrastructure to Frame to allow it to work across all connected chains in parallel.  We also added a few wallet-level features in order to allow dapp developers to easily integrate with Frame:

• A wallet_getChains RPC method to return all of the user's available chains.
• A chainsChanged event that works similarly to the events outlined in existing specifications such as EIP-1193. This event should be emitted whenever the chains available to the dapp change. In Frame this will be whenever the user adds a chain, removes a chain, turns off a connection, or a connection goes down for some reason.
• A new top-level JSON RPC payload parameter chainId that can be used to allow requests to target a specific chain. The entire payload might now look something like:

  {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "eth_sendTransaction",
    "chainId": "0x89",
    "params": [ ... ]
  }

We're now exposing this parallel chain interface so that developers can build dapps where users aren't restricted to taking action on one chain at a time. Once a connected dapp has the list of available chains it can use that information to create seamless multi-chain experiences -- such as implementing chain-specific features or routing outgoing requests to a desired chain — all without the user needing to switch back and forth. The send dapp is built on top of these concepts and showcases how dapps can feel smoother and more “native” if we build them from the ground up with web3 UX in mind.

This change and a few others that are still being worked on will form the basis of an upcoming Ethereum Improvement Proposal. The send dapp will be exhibit A in why these new standards are valuable and how they can be leveraged by developers to provide a richer and more web3-native experience.

We’ll be following up with more on what we see for the future of Frame and web3, as well as said EIP with additional details and a formalization of some of these ideas. In the meantime give the Frame send dapp a spin and come find us on Twitter or Discord to let us know what you think!

Want to get involved in one of the most exciting projects in web3? We’re hiring!

https://discord.gg/XgNfMeAB

https://twitter.com/0xFrame