Pantos Project Update — Alpha Phase insights and way toward the launch of Pantos
In today’s project update, we will present the outcomes of our initial alpha phase. In the last few months, we have put our prototype through its paces and tried to ensure the reliability and functionality of all core components. While we made substantial technical progress (which we will discuss during this update) we also want to highlight our recently announced partnership with the London Business School, just in case you missed it.
Before deep-diving into the results of our alpha phase, let’s have a look at Pantos’ current architecture and the processes involved.
In its current state, the Pantos network consists of the following core components:
• The Pantos hub
• The Pantos forwarder
• The Pantos tokens
• The Pantos validator nodes
• The Pantos service nodes
• The Pantos clients
The Pantos hub, forwarder and tokens are on-chain components, i.e., smart contracts deployed on all Pantos-supported blockchains. On the other hand, the Pantos validator and service nodes, as well as the Pantos clients are off-chain components, i.e., software that runs outside any blockchain network. These components are integral and indispensable parts of our secure, scalable and, eventually, fully-decentralised multi-blockchain system.
The Pantos hub is the main component of each supported blockchain. It connects all on-chain and off-chain components. The operators of Pantos validator or service nodes need to register their nodes and their bids at the Pantos hub contracts for their respective blockchains. Similarly, token issuers register their multi-chain tokens at the Pantos hub. All node operators and token issuers have to provide a form of stake in our native Pantos token (PAN), thus ensuring the desirable behaviour of the Pantos network participants.
The Pantos forwarder connects the Pantos hub and all Pantos-supported tokens. It verifies the user’s signature during a Pantos token transfer and ensures that the system can only process each signed transfer once and only within its defined validity period.
In the early phase of Pantos, we rely on a form of Proof of Authority (PoA) for our cross-chain validator. The validator ensures that a cross-chain token transfer has been properly processed and is fully included on the source blockchain, i.e., the blockchain of the sender, before it is submitted to the destination blockchain, i.e., the blockchain of the recipient. Based on our research results, we are currently implementing a fully decentralised system of validator nodes, which will rely on a form of Proof of Stake (PoS).
The Pantos service nodes accept client transfer requests and submit them to the appropriate Pantos hub. Their primary purpose is to allow users to pay the transaction fees for all Pantos transfers in PAN, independent of the actual source or destination blockchain. This means that users don’t need to buy any native coins on the blockchains they want to use.
Service nodes can register “bids”, as we call them, to provide their service to users. A bid consists of two variables, the transfer fee in PAN that the user has to pay to the service node and the maximum time the transfer can take before it gets reverted. Service nodes compete with each other and need to adapt to the market needs. However, holding PAN is always sufficient for initiating a transfer regardless of the blockchains involved from a user perspective. The service nodes pay the actual transaction fees in the native coins while they get rewarded in PAN.
Steps of a token transfer:
- The user initiates a transfer by signing a request.
- The user request gets submitted to a service node.
- The service node validates the request and sends it to the Pantos hub.
- The Pantos hub validates the involved token(s) and nodes and forwards this information to the Pantos forwarder.
- The Pantos forwarder verifies user signatures and instructs burn on source chain.
- The Pantos validator monitors all chains and registers incoming transfers
- After blockchain confirmation of the burn, the validator submits a token transfer request to the Pantos hub on the destination chain.
- The Pantos hub checks the incoming request and forwards it to the Pantos forwarder.
- The Pantos forwarder verifies validator signature and instructs mint on the destination chain.
For a token transfer to another blockchain, a user’s client first obtains the available Pantos node bids from the Pantos hub of the source blockchain. Then, the most appropriate bid (e.g. the cheapest or the fastest) is chosen, either automatically by the client, or manually by the user.
The user signs the Pantos transfer request locally and submits it to the Pantos service node defined by the selected bid. After validating the request, the service node sends the token transfer request to the Pantos hub.
The Pantos hub validates if all involved nodes and tokens are correctly registered and forwards the request to the Pantos forwarder, verifying the user signature. If all verification steps are successful, the Pantos forwarder indicates the burn of the appropriate amount of the Pantos-enabled token can begin.
After that, the Pantos validator, which monitors all supported blockchains, notices the incoming transfer and waits for its proper inclusion in the source blockchain. As soon as this is confirmed, the validator submits a new token transfer request to the Pantos hub of the destination blockchain. The request is checked again and then forwarded to the Pantos forwarder of the destination blockchain.
There, the validator’s signature is verified, and, if successful, the contract of the transferred token is informed to mint the appropriate amount of tokens. This amount is then credited to the recipient’s balance, concluding the Pantos transfer.
Now that we have a clearer picture of the network architecture and which steps are carried out in the background during a transfer, let’s talk about the purpose of the alpha phase and our latest progress.
Usually, an alpha phase describes an early stage of the product development used to evaluate all core functionalities of the code. So, while this usually means that not all features have been implemented, it also provides developers valuable insight. For our internal alpha phase, we have worked closely with some of the most experienced developers and QA specialists at Bitpanda to gain additional insights and feedback from them.
As a first step, we committed to the full integration of Pantos on the BNB Smart Chain and Ethereum. We have achieved this goal relatively quickly based on our previous work. Our implementation proved to be stable in the test environment during our tests. In our last project update, we announced that we would release our beta in the form of a command-line interface. However, we want everyone in our community to get their hands on Pantos and to try out our technology without needing any technical skills. Therefore, we have shifted our priorities and developed a fully functional and easy to use webapp. We will be releasing it with the launch of our beta phase. Nevertheless, we will share our CLI for anyone who may be interested in learning more.
Plus, we have more good news to share. Since the implementation of the BNB Smart Chain went smoothly, we have been actively working on integrating other EVM-based blockchains. For our beta launch, we are also incorporating layer-2 networks and plan to support at least five networks at the start: Ethereum, BNB Smart Chain, Rootstock Bitcoin, Polygon and Avalanche.
Back to the alpha: You might wonder how exactly we tested during our alpha phase. While we don’t want to bore you with too much technical jargon, we will try to provide a high-level overview.
The most basic and natural form of testing is to use the product actively and observe if the outcome is as expected. At the same time, this is a relatively simple approach to testing a product and makes it easy to miss issues. To not overlook any critical flaws or bugs, we have to use a series of tools to gain in-depth insights into the performance and functionality of Pantos under different circumstances. Since we are working in such a novel environment, we had to develop most of the tools and scripts ourselves to perform the required testing.
Below, you can find a brief overview of some of the different methods that we used and continue to use for our testing:
Manual testing
- CLI client
- Webapp
Automated integration testing
- CLI client
- Direct interaction with smart contracts
Automated end-to-end testing
- Testing functionality of all involved components and steps
While we are improving our protocol continuously without bragging about it, we nevertheless managed to substantially improve our codebase and frontend during the last few weeks. We are excited to share it with you as part of the upcoming beta phase.
During every stage of IT development, there are always some hiccups or limitations you encounter. Let’s have a look at our experience during the alpha:
One of the first issues we encountered on the test networks was that most public nodes were not reliable and sufficient for our needs, so we are running our own nodes for each blockchain through a partner to ensure the highest possible stability, speed and security. Another issue that we encountered was the congestion of the Ropsten network, which made it at times impossible to submit any transactions. As a result of the current state of the network, we decided to move to the Rinkeby testnet for now.
Finally, let’s take a look at what we are currently up to and planning for the following weeks. As mentioned earlier, our development focus has been on improving the frontend and integrating additional blockchains. While on the PR & Marketing side, we have been preparing for our go-to-market strategy to increase awareness and participation during this vital phase. The beta will consist of two main phases with different stages. The starting phase will be partly centralised. However, after the initial beta start, we will introduce service nodes as soon as we can assure the stability of the network. Following this stage, we will proceed to the complete decentralisation of the network by introducing the validator nodes.
Starting phase
- Release of CLI
- Release of the webapp
- Central validator run by Pantos
Decentralisation phase
- Introduction of Service nodes
- Introduction of Validator nodes
After completing the decentralisation phase and ultimately the beta, there will be another extensive round of internal review and testing of the final codebase. Additionally, we will have at least one external audit of Pantos to ensure the highest security standards for the network.
Do you have any questions? Don’t miss our ask-me-anything Session!
We will be hosting an AMA on Friday May 13 at 4 PM CET. Make sure to post all your questions in the ‘pantos-ama’ channel on the official Bitpanda Discord server by May 10 so that we can answer as many of your questions as possible!
Follow our official channels and join our community!
- Twitter: twitter.com/PantosIO
- Reddit: reddit.com/r/Pantos
- Facebook: facebook.com/PantosIO
- Telegram EN: https://t.me/PantosIO_EN
- Telegram DE: https://t.me/PantosIO_DE
- Telegram Announcements: https://t.me/PantosIO_announcements
- LinkedIn: linkedin.com/company/Pantos_IO
- GitHub: github.com/pantos-io
- Discord: discord.gg/bitpanda
