Launched on 5 Testnet networks

Allgate contracts have been deployed on 5 blockchains: Ethereum Goerli, BNB Chain Testnet, Polygon Mumbai, Avalanche Fuji, and Fantom Testnet.

Application

We encourage everyone to participate in our Testnet using Dapp at: https://www.allgate.io.

Testnet Phase One - The scope

Ultimately, Allgate will enable the creation of entirely new OFTs (Omnichain Fungible Tokens standard developed by LayerZero) and make existing tokens OFT. For now, during Phase One, we are focused on the abovementioned possibility of quickly deploying your own OFT from scratch. The latter feature will be introduced in Phase Two of the Testnet.

That being said, here’s the official Guide on how to use Allgate.

Guide - Deploy your OFT

Go to our Dapp and use the Create OFT button.

Choose the New OFT option. The Proxy OFT (Migration, existing tokens) is of out the scope of Phase One and will be enabled starting from Phase Two.

Fill out the basic token details form. Set the OFT name, symbol, decimals (18 is the most common option) and total supply - this is the number of tokens that will be minted to your address as a deployer.

Connect your wallet and click on the Deploy button. After the transaction completion, you’ll be redirected to your new OFT Page where you can manage your token.

Note, that currently your OFT is not connected to any OFT on other chains. Use the steps described above to create your second OFT on some other blockchain. In this example, we’ve deployed our OFTs on Polygon Mumbai and Fantom Testnet.

Next, go to your first OFT Page again and click on the Connect remote OFT button. Paste the token address of your second OFT and select its chain. Confirm the transaction.

You should be able to see now that your first OFT has 1 remote (chain) connected. That’s why the basic charts for tracking your OFT transfers, inflows, and outflows, should become now available (but still empty).

It’s necessary now to go to your second OFT Page and repeat the Connect remote steps to connect your second OFT with the first OFT. Each connected OFT (remote) should be connected in both directions. This provides a security mechanism for OFTs to only accept cross-chain transfer requests from trusted remotes.

Now, after you have connected at least 2 OFTs, you can **go to the Transfer Page. **Connect to the chain (network) on which you have deployed your OFT and paste your OFT (from this chain) address. Click Next.

In our case it was Fantom Testnet with the OFT address: 0x7912b85a17e30dba071670a33fb3a32de0873d23.

Now, the only thing left is to set the destination chain (click on the bouncing destination chain icon. You should see 1 chain available - the one that you set as remote in the previous steps) and the amount of the transferred tokens. Click the Send button and confirm 2 transactions - Approve and Send. Make sure that you have enough tokens in your wallet.

After the transaction completion, you should be able to look into the LayerZero Scan Explorer. Usually, tokens transfer should complete at the destination within 1-3 minutes.

The transaction is successful. Note that the LayerZero Scan usually updates the status a few minutes after the real transaction completion.

Summary

To sum it up, we understand there’s a lot to it, especially for non-technical users. The Transfer (bridging) part is simple but the OFT creation and management part is designed to make things easier and more automated for future real OFT deployers (project owners). Using Allgate, the deployment of OFTs and making existing tokens OFTs is simple and doesn’t require technical knowledge. We also provide analytics for your created tokens and the ability to connect deployed OFTs via UI. For the everyday user, the most often-used part of the Dapp will be the Transfer Page where we can simply move our tokens between connected chains. Nonetheless, we encourage everyone interested to at least try on their own to complete the steps - deploy your own OFTs, connect them, and transfer tokens between chains.

Because of the abovementioned reasons, Allgate Team will now mainly focus to:

1. Process the feedback from Users who at least managed to complete all the steps.

2. Track the on-chain results of your activity regarding the OFT creation and transfers.

3. Work on delivering Phase Two of our Testnet.

We plan to divide it into 3 phases, each of which will focus on testing the most important components of Allgate. One such component is the SubZero protocol. Let’s talk about it and explain how it’s going to change Web3 and especially DeFi by making all existing protocols Omnichain by default.

Context

Cross-chain architecture and solutions enable/improve:

• User Experience due to the Web3 infrastructure abstraction.

• Openness to protocols from different chains (including between EVM and non-EVM) which increases composability.

• Interacting with contracts regardless of what network a User is connected to.

• Cost-efficiency, Time-efficiency, security (No bridging, direct transactions, fewer steps to accomplish task).

The growing adoption of cross-chain general messaging protocols (GMPs) such as LayerZero or Axelar has led to the emergence of new protocols claiming their superiority over “old” single or even multi-chain (but not cross-chain) applications. In all fairness, on first look, it’s a valid statement because chain-agnostic contracts can indeed allow to abstract away Web3 infrastructure - for example the necessity to bridge tokens or switch between networks in a wallet in order to use certain Dapps.

So, what about well-known, trusted, highly liquid, and important protocols such as Aave, Compound, OpenSea (Seaport), Maker/Dai, Uniswap, and more?

Introducing SubZero - our way to make all protocols Omnichain.

SubZero is one of our core components and is technically a protocol on its own. It enables the following:

1. All existing contracts become cross-chain without any action from their side.

2. Users can use any protocol from any chain without switching networks.

3. Support for all kinds of transactions - involving tokens or tokenless.

4. Easy for developers to use and make User Interfaces on top of it to make interacting with SubZero seamless.

Too good to be true? No. Here are some examples of what will be possible:

• Adding supply to Aave from BNB Chain.

• Borrowing on Compound from Aptos.

• Exchanging tokens on Uniswap from Metis, Moonbeam, zkSync, etc.

• Buying Ethereum’s NFT on OpenSea from any chain.

• Sending NFT and fungible tokens while being on a different chain.

• Transferring your tokens from Ethereum to Optimism while not being connected to Ethereum (for instance, you’re on Optimism).

• Infinitely more…

Cross-chain transactions chaining

It’s not everything yet. Imagine you want to buy NFT on Aptos using eg. USDC, and you are even connected to this network, but you don’t have your stablecoins on Aptos - you have it on for eg. BNB Chain. Thanks to SubZero being able to perform cross-chain transactions chaining we will enable you to batch in one transaction the following operations:

1. Initiate operation from the chain you’re connected to (Aptos) - it sends a message to the chain where you have tokens (BNB Chain).

2. On receive, your USDC on BNB Chain will be sent to the desired network (Aptos in this case).

3. On receive, again on Aptos, your transferred (incoming) USDC will be used to perform the operation’s final transaction - buying NFT.

How will it work from a User perspective?

You probably used a Dapp before that displayed to you “Wrong network“ or “Switch network“ messages. The end goal for SubZero is to make it a relic of the past. Anytime you see these errors/blockers know that this Dapp will be able to use SubZero to allow you to interact from your chain, and not require Users to have technical knowledge, change networks, bridge assets, etc.

No changes to the underlying protocol’s contracts are required. In the example above, all 3 transactions (2 cross-chain) will be routed and executed by SubZero. At first, Allgate will build and share the User Interface to interact with the most reputable and popular (probably even mentioned above) Web3 protocols with SubZero utilized as the underlying technology. All the User will see is the applications list (eg. Uniswap, Compound, Aave, etc.), and after selecting one - the list of actions specific to the chosen app (swap interface, add supply button, […]). In general, at the very beginning, we’ll serve as the protocols aggregator with SubZero working in the background (Omni Apps). In the end, our plan is to encourage protocols to utilize SubZero on their Dapps.

SubZero core components

• SubZero - Entry contract with immutable address (Proxy) responsible for accepting and validating input.

• SubZeroRouter - Routing a cross-chain transaction depending on the next call target (third-party contract, eg. Aave) destination chain.

• SubAccount - The most crucial core component of SubZero protocol infrastructure. It serves as User’s Omnichain Account as well as an arbitrary transaction executor. What SubAccount is:

  1. Independent contract using Adapters allowing SubAccount to be upgradeable (only by the owner), future-proof, and protocol-agnostic.

  2. Cross-chain application on its own - accepts LayerZero messages, Stargate messages, OFTs messages, etc.

  3. Account Abstraction - smart contract account owner is able to use (including cross-chain transactions) even without SubZero.

  4. Delegated transactions executor (caller) - performs calls as a msg.sender, provides a fallback mechanism for failed cross-chain transactions and funds recoverability.

• Adapter - Module that introduces additional capabilities to utilize by a SubAccount. By default SubAccount use AllgateAdapter, LayerZeroAdapter, and StargateAdapter. Some may be used for general messaging passing between SubAccount instances across chains (LayerZero), and some are explicitly used for cross-chain composable calls involving tokens (AllgateAdapter for OFTs, StargateAdapter for Stablecoins). Each added to the SubAccount Adapter is removable from the Adapters mapping by the SubAccount owner. In the future, Allgate will provide more SubZero Adapters for owners who would like to upgrade their SubAccounts with more capabilities. Examples of such incoming Adapters are - AxelarAdapter, ConnectXAdapter, etc. Each of these could potentially extend SubAccount’s cross-chain possibilities by providing support for various chains.

Next-gen Account for all Web3.

If you’ve read the above section, there’s a chance that you share our excitement about the new possibilities that the SubZero protocol with its SubAccounts present to every Web3 User.

The ability to completely abstract Web3 infrastructure. For the Users, it means never again switching networks in their wallets to use a specific protocol or Dapp. Never again having to bridge tokens to be able to make use of them. Always being able to use tokens that you hold on multiple chains as if they were on the same chain/account. And the list of benefits goes on and on. For the protocols (Teams), it means not having to deploy or modify any code/changes to be cross-chain compatible.

So, let’s have it! This month we’ll launch the first phase of the Allgate Testnet. At this stage, our focus will be the testing of new OFTs creation, cross-chain transfers, management, and error handling. The second phase of the Testnet will concentrate on the Migrations - their various strategies and Holders onboarding. Lastly, the third phase of the Testnet will be designed to prepare, test, and optimize the SubZero protocol on some real-world applications like Compound or Uniswap and their official testnet contracts. We’ll also make sure then to audit the contracts and implement each potential fix and improvement on every possible level to make Allgate secure, reliable as well as friendly for Users and developers. In the meantime, our intention is to build a valuable product, an initial user base, and partnerships with other projects.

Omnichain Fungible Tokens (OFTs) standard developed by LayerZero enables a token to be natively sent between blockchains. Here are the significant features it introduces.

• No third-party contracts (bridges) are needed anymore.

• Cross-chain Composability: able to call any contract after a successful transfer.

• No requirement for liquidity (no Pools on chains for transfers).

• Future-proof: Each OFT is able to add more (even not existing yet) chains.

• Total supply is capped across all connected blockchains.

• Transferability between EVM and non-EVM chains (e.g. Aptos).

• Standard used by BTC.b: Allgate wants to make it common for any Token.

Allgate’s mission is to make it possible for any token (new and existing) to become OFT. Our vision is the emergence of Omnichain DeFi which we’ll explain and analyze in the next article.

OFT deployment via Allgate

Having that said, it’s important for Project Deployers to know how to use the OFT standard. Let’s answer this question in two scenarios:

• A project’s token doesn’t exist yet on a given chain: Create a new OFT.

• A token that already exists on a given chain to become OFT: Use Migration.

Obviously, Allgate will support both cases, all via a no-code, easy-to-use User Interface.

A) Create a new OFT

Allgate will enable a new OFT deployment via our dApp in a few simple steps:

1. Set Token name, symbol, decimals, and supply.

2. OFT supply is minted to the deployer address.

3. Deploy on each chain you want your OFT to exist on. You can even start with zero supply on a given chain and transfer tokens there from your OFTs on different chains that already have some tokens in circulation.

4. Allgate creates a dedicated OFT Page where Holders can transfer (bridge) between chains. This is just a User Interface for OFT native contract capability.

B) Create via Migration to onboard your existing Holders

1. OFT name and symbol are by default the same as the Migrated Token. The circulating supply is set to zero and will increase along with each migration (Holder’s 1:1 swap from Migrated Token to OFT).

2. Optionally, Deployer can set advanced Migration settings such as starting date, allowlist, etc.

3. A Migration contract is deployed automatically to enable Holders a 1:1 swap between the Migrated Token and OFT.

4. Allgate creates a dedicated Migration Page for Holders to easily migrate to OFT.

5. Allgate creates a dedicated OFT Page where OFT Holders can transfer (bridge) between chains. This is just a User Interface for OFT native contract capability.

6. If your Migrated Token is multi-chain, perform Migration to OFT on each blockchain.

Deployment Examples

Example Scenario 1:

Your token contracts already exist on Ethereum and BNB Chain. You want to connect them.

Use Migrations. For instance firstly on Ethereum and secondly on BNB Chain. Follow the instructions in the dApp (the abovementioned steps). Allgate will give you dedicated Migration Pages for Ethereum and BNB Chain where your Migrated Token Holders will be able to swap 1:1 to the OFT.

Next, you will go to the Dashboard and easily Connect all your OFTs (setting Remotes).

Example Scenario 2:

Your token contracts already exist on Ethereum and BNB Chain. You want to connect them and additionally enter Aptos and Polygon (or more).

After completing the steps described in the first example, you’ll now want to use the “Create new OFT“ option firstly for Aptos and next Polygon (or more chains). Follow a few simple instructions in the dApp (the abovementioned steps) to have your OFTs deployed.

Next, you will go to the Dashboard and easily Connect all your OFTs (setting Remotes).

Example Scenario 3:

Your token doesn’t exist yet anywhere. You want it on all EVM chains and Aptos.

Use the “Create new OFT“ option for each EVM chain and Aptos. Follow a few simple instructions in the dApp (the abovementioned steps) to have your OFTs deployed.

Next, you will go to the Dashboard and easily Connect all your OFTs (setting Remotes).

OFT management via Dashboard - Connecting, Analytics, and more.

Connecting OFTs together:

The last step described in each example refers to setting Remotes which is nothing more than telling your OFT on each chain to “trust” only a given address on a different chain (OFT address on that chain). This creates Connections between all your OFTs and therefore enables them to communicate (transfer) across chains. Setting Remotes is designed to reject cross-chain transactions from unauthorized contracts on different chains.

Analytics:

Track statistics, charts, transactions, and migration status of your OFT on all chains. Understand what’s happening, and make better conclusions.

Omnichain DeFi is coming

We believe that the popularization of the OFT standard as a native cross-chain primitive will lead to the emergence of Omnichain DeFi and other Web3 use cases.

In 2022 Decentralized exchanges alone executed $854 billion in trading volume. The idea of gradually interconnecting (with full composability) protocols such as Uniswap as well as other DeFi protocols categories like Lending (e.g. Aave, Compound), Derivatives, Perpetuals, Yield Farming, Stablecoins, and so much more, can result in the creation of multi-trillion dollar DeFi market’s segment. We’ll dive more into the concept of Omnichain DeFi in the next article.

The Problem

Out of respect for your time, we will not describe here what Web3 and crypto are, and what is its purpose. The most important thing we would like to share at the beginning is our observations about the incredibly large, dynamic, and constantly growing ecosystem of decentralized applications, protocols, and blockchains on which these applications are created - why it's a good thing but simultaneously what problems does it present?

• The growing number of ecosystems makes them by default disconnected and fragmented.

• Web3 protocols are all about composability  -  creating a "Financial LEGO" effect that allows developers to connect applications together. Protocols' inability to communicate with each other due to ecosystems fragmentation leads to decreased composability.

• Most of the projects see that and try to go with a multi-chain approach - deploying contracts and being present on more than one blockchain. These contracts are usually disconnected, and separated. Users connected to Uniswap on Ethereum can't directly trade a token that is available on Uniswap's Polygon instance. That user would have to switch networks in the wallet first. Even then, he/she would still need to have funds there (on Polygon wallet). Usually, it involves for example selling Token A on Ethereum, bridging it using a third-party bridge to Polygon (if supported by any bridge), and trading that bridged, wrapped token on Polygon for Token B. Moreover, if a Token A isn't directly bridgeable, the User would need to trade it first on Ethereum (or CEX) for a tradeable token (most likely ETH or a stablecoin) and only then complete the next steps. A side note here: Allgate will solve this exact problem and more - as Token A will become Omnichain (OFT), there won't be a problem to transfer it (in the background) between chains and trade it for Token B in a single User's transaction (cross-chain composability).

• Trading is just one example that shows how ecosystems (blockchains) fragmentation leads to breaking composability and therefore to the inability to perform certain actions on tokens. The same can be applied to paying for an NFT mint (primary sales) or trade (secondary sales), building liquidity, investing in IDO, and participating in any activity that involves any token usage. In the end, a User needs to be connected and to have funds on the same chain as the application/contract.

• Poor User Experience and steep learning curve  -  currently a new Web3 User has to think about chains, networks, switching between them, and even complex topics like bridging assets. Does a Web2 application user need to know anything about Netflix's backend architecture - for example what is the role of a given microservice? Of course not. It would lead to a horrific UX and a fraction of the usage Netflix has nowadays. And this is the state of current Web3 applications. The solution is to abstract the decentralized infrastructure away and allow Users to focus only on a product. The Omnichain approach and technology developed by LayerZero do exactly that. A User can therefore use application(s) deployed on multiple networks as if they were one.

Our Solution

Our vision at Allgate is to seamlessly connect all fungible tokens with full composability by making them OFTs (Omnichain Fungible Token standard proposed by LayerZero).

Create new or Migrate existing tokens to OFT: When interacting with Allgate, a User’s first choice is to choose whether to a) Deploy a new OFT from scratch. b) Migrate existing token to the OFT standard.

Option A is probably pretty clear — it involves just a few clicks and inputs for the token’s name, symbol, decimals, total supply, etc. After confirmation, the new OFT contract is being deployed.

Option B is easy to understand and use too, but it’s probably the most exciting part of our mission. The ability to make any existing token Omnichainable by making it OFT via customizable Migration. We’ll talk about configurable Migration parameters in detail in a dedicated article but what we’d like to highlight here is just that it will allow all Token Deployers (Founders, Teams, or DAOs that manage the token) to conduct a migration process using our no-code interface. In this process, the OFT’s supply is not minted on deployment — instead, it allows any Migrated Token’s Holder to swap the old token to the OFT in a 1:1 ratio. Describing briefly, we support:

• 13 EVM chains (Ethereum, Polygon, BNB Chain, Avalanche, Optimism, Arbitrum, Moonbeam, Fantom, Harmony, Celo, Klaytyn, Gnosis, Fuse) and 1 non-EVM (Aptos) blockchain. The list of chains will only grow.

• (Optional) Holders Allowlists (allowing you to use a snapshot if needed).

• (Optional) Choose between a Single/Bi-directional migration. Single by default means no coming back after migrating to OFT. Bi-directional allows holders to roll back to the old token. In the case of a Single-directional migration, the Migrated Token is burned with each swap. When using Bi-directional migration, the Migrated (old) Token is not burned, but instead locked in the contract, and burned only after the migration completes with a separate deployer’s transaction.

• Doesn’t matter if your Migrated Token exists on only one blockchain or is deployed on multiple chains — we will connect them natively using Migration for all instances. OFT on each supported chain is set as a “remote” contract.

• You no longer need a third-party, external bridge. Each OFT is transferrable on its own on the contract level across all supported chains.

• We provide a default interface for each created OFT and its Holders to make the bridging immediately available without a need to build a custom UI. But in the end, the OFT is fully decentralized, doesn’t rely on any third party, and can be obviously used even on a code/contract level with full composability or via Etherscan, etc.

The more tokens we’ll be able to connect the closer we will get to the common Web3 ecosystem with many blockchains and applications interacting with each other invisibly for the end Users.

Ultimately, in a perfect scenario and with our end goal realization, wallets could definitely stop showing networks to choose from as all tokens, applications, and protocols would be interconnected at the infrastructure level.

Our Omnichain mission begins now with the Testnet estimated to launch in February.