Whitepaper
The aims, vision and functional basis for Blessnet.
Vision
Blessnet aims to create a more interconnected and efficient Ethereum ecosystem, where users can interact safely across multiple chains while keeping their valuable assets secure on established networks.
Vertical Scaling for Ethereum
Layer 2 solutions greatly increase the blockspace available in the Ethereum ecosystem. They allow reduced transaction cost and expand the use cases for smart contracts. They drive innovation and allow builders to connect with users in new and exciting ways.
Layer 2 solutions also fragment the Ethereum ecosystem, carving liquidity into disparate silos. Users are left tracking assets across a range of chains and contract addresses. Complexity increases, and the user experience suffers. While there are other proposals for reducing this fragmentation, all of them seem years away from delivering a solution.
A key metric for Layers 2s is TVL (total value locked), with projects competing to lock as much value as possible on their Layer 2. A Layer 2 ‘wins’ when it pulls the most value into itself, regardless of the health of the ecosystem as a whole.
It’s easy to see this as horizontal scaling. Total capacity has been increased by the addition of numerous silos running side-by-side above Ethereum mainnet. There are more places to transact, but they are all doing so separately, with little overt involvement of other chains.
At the same time, users generally want mainnet assets. They naturally want low transaction fees. But at the end of the transaction they would like to hold mainnet assets.
Blessnet is an entirely new type of chain, with the express aim of delivering vertical scaling to Ethereum. Blessnet’s infrastructure supports transactions that either originate from or settle assets on other chains. Blessnet is a chain where you do things, with your valuable assets residing on other chains. Blessnet therefore works in direct partnership with existing chains; it’s aim being to enhance the overall ecosystem, and build as little TVL on itself as possible.
Functionality and Safety
Crypto assets should do things. At a basic level most assets can be traded, but there are a vast and growing number of use cases for crypto assets. A common example is using the ownership of an asset to offer rewards. This might be the membership of a on-line community, participation in an NFT mint, or an airdrop allocation.
Rewarding the holders of existing assets in this way can be hazardous. Users often need to prove their ownership of assets in such a way that exposes those assets to risk, for example claiming an airdrop with the wallet that holds the NFTs.
Blessnet provides a level of abstraction from the chain where assets reside, by allowing users to make claims on Blessnet. Users can still use the same wallet as on mainnet, but they are not signing a mainnet transaction. All on-chain transactions include a chain identifier. A transaction submitted with the chain ID of Blessnet (45513), cannot be executed on a chain with another chain ID (e.g. chain ID 1 for Ethereum Mainnet). As the underlying assets are not on Blessnet they cannot be transferred by a transaction submitted on Blessnet.
The mint of the mainnet assets that are being airdropped can then be sent cross-chain from Blessnet to mainnet. This means that the user has never had to connect their wallet on mainnet. They have never had to potentially put mainnet assets at risk. But at the end of the claim they still have new mainnet assets.
Value Bearing vs Transaction Processing
Within the Blessnet team we talk about Value Bearing Chains (VBCs). These are the chains where valuable assets should be stored. The names of these chains are familiar, and include Ethereum Mainnet, Arbitrum, Optimism and Base.
Transaction Processing Chains (TPCs) on the other hand are not where valuable assets are stored, but where users perform actions. These are the chains where users play games, take part in votes and claim airdrops.
For asset safety - and user peace of mind - there should be separation between TPCs and VBCs. Taking part in an on-chain vote should be very cheap, and leave you with absolutely zero concern that you are doing something unintentional with assets on VBCs.
The barrier for creating a new TPC can be quite low. The value of the TPC is in what it allows you to do, not its TVL.
The barrier for a new VBC should be very high! People want to know that their assets are held in the most secure location possible. And - ideally - users should only interact with the VBC when they want to move assets. Everything else should take place on TPCs.
Blessnet’s philosophy is that we have sufficient VBCs already, but that we need more TPCs that are focussed on allowing people to do more safely, which eschewing any attempt to accumulate a high TVL. TPCs avoid a high TVL by leaving existing assets on, and delivering new assets to, VBCs.
Bringing off-chain back on-chain
The use of off-chain signatures has surged in recent years, with an increasing number of protocols using signed arbitrary messages. The advantage of this approach is clear: users can interact with protocols without incurring an immediate gas cost. This move was in part driven by blockchain congestion and therefore very high gas costs.
We now have a relative abundance of blockspace. Many of these off-chain workflows should come back on-chain. Blessnet facilitates this by providing very cheap blockspace where developers can both interact with data from other chains and easily settle valuable assets on established, value bearing chains (VBCs).
Mirrors and Ethereals: Through the looking glass
Blessnet’s ultra-cheap blockspace and all-ecosystem philosophy allows it to do things that no other chain can. Among these are Mirrors and Ethereals.
Mirrors
Development Status: Live
Where useful data is available on other chains Blessnet can mirror this data in real-time. This allows users to make use of the chain features they are accustomed to, from a range of protocols and potentially from a range of chains.
Our first set of mirrors is for delegations. Data from a range of delegation protocols is replicated in real-time on Blessnet, allowing smart contracts to make use of this valuable data without the need to transact on mainnet or other value bearing chains.
Ethereals
Development Status: Q4 2024
Ethereals take a similar approach to mirrors. Ethereals are Blessnet real-time mirror images of tokens and collections on another chain.
Whereas Mirrors operate to reflect whole infrastructure protocols, such as delegations or address naming registers, Ethereals operate at the token standard level. This generalised architecture allows any user to setup a Blessnet Ethereal for an ERC-20, ERC-721 or ERC-1155 token on another chain.
Only one Ethereal can be created per contract address per chain. For example, only one Ethereal collection for contract address 0x1D20A51F088492A0f1C57f047A9e30c9aB5C07Ea from chain 1 (Ethereum Mainnet) can be created.
Creating an Ethereal results in a Blessnet contract that replicates its source contract in real-time. The user who created the Ethereal has no special privileges on this contract, but they do seed the contract with BLESS to pay gas for real-time replication. Any user can, at any time, seed additional BLESS to the contract to pay for future gas. Seeded BLESS cannot be withdrawn.
Ethereals cannot be transferred or traded in any way. They follow what happens on their source chain in real-time.
Why Mirrors and Ethereals?
Mirrors and Ethereals allow users to interact on Blessnet as if they were on another chain. For example, you can build a protocol that uses delegations made on mainnet. Or you can hold a vote for all holders of a given NFT, by using the Ethereal contract on Blessnet.
Do you have an end result that needs to affect another chain, for example the result of a vote? Blessnet is built for this too, and you can achieve this through the Transaction Pool.
Transaction Pool
Development Status: Live
The Blessnet Transaction Pool is used to send transactions from Blessnet to other chains.
The Transaction Pool itself is on-chain. It supports a simple interface that developers can use to submit cross-chain messages.
Contracts interacting with cross-chain messages from the transaction pool can implement a simple base contract for message delivery.
CRON-type On-chain Jobs
Development Status: Q2 2025
In addition to supporting atomic cross-chain messaging, the transaction pool has been designed to facilitate CRON style interactions, including the scheduling of repeating on-chain jobs.
BLESS: Self-bridging, Natively Multi-chain
Development Status: Live
BLESS is the native gas token of Blessnet. It has a fixed supply of 1 billion tokens.
All tokens have been minted. There is currently no vesting or emissions schedule.
Seamless Bridging
Blessnet aims to support the entire Ethereum ecosystem. In reflection of that BLESS is natively multi-chain.
On Blessnet BLESS operates as a standard gas token. When not on Blessnet BLESS is an ERC20 token with cross-chain technology baked in. The token contract includes self-bridging methods that leverage Wormhole and the Arbitrum Nitro rollup bridge. This allows BLESS to bridge itself between supported chains.
BLESS bridging consists of three possible flows, as illustrated below.
Single Contract Address
The BLESS ERC20 is deployed using the CREATE2 opcode to supported chains, meaning that it has the same contract address no matter where you as using it. You don’t have to remember an endless list of contract addresses that vary between chains.
On mainnets the BLESS contract address is 0x000000000000CCA70B6e0997a94681a3114EdDD7
On testnets the BLESS contract address is 0x0000000000BBfbab0236d05c06211853f812ec57
The BLESS self-bridging ERC20 token is currently supported on the following chains:
Ethereum Mainnet
Arbitrum Mainnet
Optimism Mainnet
Base Mainnet
Polygon Mainnet
Blast Mainnet
Ethereum Sepolia
Arbitrum Sepolia
Optimism Sepolia
Base Sepolia
No Large Bridge Balances
As BLESS can self-bridge it does not need to rely on external custodial bridge contracts.
Instead, when moving from chain to chain BLESS is burned on the sending chain and minted on the receiving chain. This eliminates the need for large custodied balances on numerous chains.
The exception is the Arbitrum Nitro rollup bridge that custodies BLESS ERC20 tokens that are represented as native gas token on Blessnet.
Enhanced UX
Self-bridging allows BLESS to eliminate some of the poor UX commonly experienced when bridging assets, particularly to rollup chains.
BLESS can be bridged from any supported chain to any supported chain in a single user transaction. The contract itself mplements the required route to the destination chain.
This includes native withdrawals from Blessnet itself. Traditionally for rollups this involves a number of user actions. For example, moving from a rollup to a non-parent chain would involve three user initiated transactions. A withdrawal transaction on the rollup, a transaction on the parent chain to receive the withdrawal, and then a further transaction to bridge to the destination chain.
BLESS bridging has eliminated these further calls, allowing the user to make a single withdrawal transaction on Blessnet and have BLESS delivered to the chain of their choice.
Improved Traceability
All movements of BLESS are tracked in realtime, and can be interrogated on demand. In the future we will have a user interface to enable everyone to keep updated with the status of their bridged BLESS.
Governance Ready
The BLESS ERC20 implements ERC20Votes for on-chain governance.
BLESS is Built to be Used
BLESS is built to be used, both as a gas token for Blessnet transactions and as forwarded native token for delivering transactions to other chains.
Gas is very cheap on Blessnet. You will never need much BLESS to perform transactions on Blessnet. There is no purpose to holding any excess BLESS on blessnet itself that you do not intend to use as payment for gas.
Cross-chain Data Aggregation
As Blessnet can draw from many protocols on many chains it provides a unique degree of cross-chain data aggregation. This allows Blessnet to offer some unique services. Examples are provided below.
Blessnet Attestations
Development Status: Live
A number of popular protocols require users to link their asset holding wallets with their off-chain accounts. There are various ways to achieve this, with one common way being having the user sign a message with the private key for the address that holds the assets.
Users can be reluctant to do this. Often high-value assets will be in cold wallets that cautious users do not ‘put live’ unless under exceptional circumstances. Further to that, some users have a personal policy to not sign arbitrary messages.
Users need to sign a message for each address they wish to link.
To link an address using Blessnet the user makes an attestation transaction on Blessnet mainnet. The user does not need to use the private key for the wallet with high-value assets. Rather they can use any address that has a link to their high-value address on popular delegation protocols.
The Blessnet attestation transaction proves that the user is authorised to link all of the addresses that are associated with the attestation address. This allows the user to link many addresses with a single transaction.
Cross-chain: Current and Future Approaches
Cross-chain transactions, in both directions, are fundamental to Blessnet’s mission. We therefore have a plan to continually strengthen this process.
Please note that the below refers to cross-chain transaction only, not BLESS bridging. BLESS bridging uses Wormhole and the Arbitrum Nitro rollup bridge.
Phase 1: Mainnet Beta, Oracle Based Delivery
Development Status: Live
Blessnet is currently in mainnet beta. During this phase all cross-chain transactions are delivered by the Blessnet oracle.
The Blessnet oracle is a trusted, centralised service run by Otherchain Labs, the providers of Blessnet.
Using this approach has enabled us to move rapidly into mainnet operations, albeit in beta. The centralised nature of the Oracle should be noted by all users of Blessnet cross-chain transactions. If use of a centralised Oracle for delivery is not acceptable we recommend waiting until phase 2.
Phase 2: Wormhole Query
Development Status: Q4 2024
Phase 2 will make cross-chain transactions significantly more robust by including Wormhole Query.
While delivery will still be performed by an Oracle, all transactions will need to include a signed VAA from the Wormhole Guardians in order to be processed.
This will significantly reduce the centralisation risks presented by phase 1.
Phase 3: Storage Proofs
Development Status: Q2 2025
Phase 3 of Blessnet cross-chain transactions will likely involve storage proofs, providing a further level of decentralisation to our transaction delivery approach.
Modular Permissions
Development Status: Q4 2024 / Q1 2025
Blessnet is a chain for doing things, with an emphasis on doing things cheaply, conveniently and confidently. Abstracting your interactions away from Value Bearing Chains plays a big part in this. Blessnet Modular Permissions further enhances this architecture.
Delegating certain permissions from one address to another address is not a new concept. The purpose is to narrowly scope what another address can do on behalf of your ‘main’ address. This allows you to interact using this other, less valuable address, but only in the ways you define.
In all current implementations of this you need to have this second address before you begin. For example, you have your main vault address and a hot wallet in a browser extension. Delegating from your vault to your hot wallet is straightforward, but you still have to have your hot wallet ready to go.
Blessnet reimagines this process as something as intuitive as using a game controller. In Blessnet your main address is the console, and you can create multiple controllers for that console, each with a set of permissions.
For example, let’s say we have our vault address, which we will call vault.eth. This address, vault.eth, is now our Modular Permissions console. We then create a controller and assign this permission to vote on behalf of vault.eth.
The implementation of this controller is a smart wallet, with a new private key and a new public address. At the same time Blessnet will prompt you for a transaction that confirms the delegation of voting permissions from your console (vault.eth) to your new controller.
You can now use your new controller to take part in votes on Blessnet on behalf of vault.eth. You never need use vault.eth for these votes, keeping it and the assets it holds safe. And as the controller is a smart wallet, you can submit your transaction directly from the app. If for some reason your controller is compromised you can simply detach it from your console, and if needed create a new controller.
The diagram below summarises this example.
Example User Stories
Blessnet’s capabilities may be best understood with examples. In this section we detail a number of example user stories.
Example One - Cross-chain Claim
In this example we have a new ERC-20 token on mainnet Ethereum. This token has a portion of its supply allocated to users based on their holding of existing NFTs.
Barry has been allocated 1,000 tokens based on his NFT holdings. Barry is a cautious user and holds all his NFTs in and EOA (externalls owned account) cold wallet. We will call this cold wallet barryvault.eth.
Barry doesn’t want to connect barryvault.eth to mainnet. Fortunately for Barry the claim process implements Blessnet, and he can claim his tokens without ever touching mainnet.
For Barry the process involves him making a claim transaction on Blessnet. He can see that he is signing a transaction for chain ID 45513, not mainnet (chain ID 1). As he is signing a transaction, rather than an arbitrary message, he knows that what he is signing can only effect the assets he holds on Blessnet. Barry has nothing on Blessnet other than a small amount of BLESS, which is Blessnet’s native gas token.
Barry controls the address associated with barryvault.eth on all EVM chains, including Blessnet. He therefore proves control of that address on mainnet by submitting the transaction on Blessnet.
The flow of this transaction, on Blessnet between chains and on mainnet, is summarised in the diagram below.
Barry’s transaction creates a permanent on-chain record in the Blessnet transaction pool (the green box above). It also emits an event that is picked up by the Blessnet cross-chain Relayer. the transaction also takes a quantity of BLESS token that is used to offset the gas used on the delivery to mainnet Ethereum.
The Blessnet Relayer implements the transport layer method that has been configured for this claim. The above example is using Wormhole Query to generate a signed VAA (Verified Action Approval) that the receiving smart contract can use to verify the data it receives. This is the Phase 2 implementation of Blessnet’s cross chain messaging. In mainnet beta (Phase 1) messages are delivered in trusted Oracle mode, without use of a Wormhole VAA for validation.
The NFT contract on mainnet Ethereum receives the cross-chain message, validates the source and its contents, and mints the ERC20 token to barryvault.eth.
In this example Barry has claimed his mainnet token without needing to make a mainnet transaction. Since he has not interacted directly with mainnet Ethereum he is protected from unintentional mainnet asset transfers.
Example Two: Delegated Cross-chain Claim
This example is an extension of Example One. Read that one first before reading this one.
In this example we are also doing an airdrop claim, but this time we aren’t using the wallet that has the allocation.
In this example our wallet barryvault.eth has, at some time in the past, delegated authority to wallet barryhot.eth. This delegation was performed on mainnet Ethereum from one of a number of popular protocols. Blessnet mirrors new delegations and revoked delegations in real-time, so the Blessnet delegation mirror is aware of the delegation between barryvault.eth and barryhot.eth.
The claiming flow is broadly the same as in example one, but here the claim contract makes a check on the Delegation Mirror that the connected address, barryhot.eth, is authorised to make this transaction on behalf of barryvault.eth. This is shown in the diagram below.
Example Three: Modular Permissions Cross-chain Claim
Expanding on example 2, we can also make this claim using a Modular Permissions smart wallet setup for the console address barryvault.eth. For details on Modular Permissions see the Modular Permissions section.
When using a controller the process flow is very similar to our delegated claim, with the exception that it is the smart wallet associated with the given controller is checked for the permission required. This example is summarised in the below diagram.
Blessnet’s Principles
A True App-Chain
Blessnet is an App Chain in the truest sense of the term: it exists as a place for interactions, as a place to do things. Blessnet’s target TVL is ZERO. It doesn’t want your existing assets; they can stay exactly where they are! Blessnet wants to be the a place you can do the fun, useful and rewarding things that your assets allow you to do, with a focus on safety and a well-considered a user experience.
Economically Stable and Sustainable
Blessnet is focussed on being economically sustainable. It doesn’t want a large TVL and isn’t at all interested in the burden of a hyper-inflated valuation. Blessnet has a constant and granular understanding of the operating costs of the chain, and how these are defrayed by users spending BLESS token for transaction costs (gas fees). Our economic cornerstone is coverage of operating overheads with the revenue from gas fees. This sustainable economic focus gives us the launch-pad to tackle our more ambitious long-term aims, and gives us freedom to experiment in ways that very few chains can.
Low Costs and Low Holdings
Our architecture guarantees very low transaction costs. A small amount of our native gas token BLESS will go a long way, particularly if most of your transactions occur on Blessnet and not across chains. The sole reason to hold BLESS is so you can pay for transaction costs. So you are never going to need a lot of BLESS. Don’t hold more than you need!
Focus on User Experience
In crypto the user experience tends to come second. And sometimes not at all.
At Blessnet our aim is to always circle back to the user experience. Something can be technicaly exciting. But unless it’s also usable we won’t proceed.
Last updated
