Project Update Part I: Alpha Launch — Be part of the Pantos Revolution
Today, we want to once more celebrate our recent milestone, our first Pantos cross-blockchain transfer in public test networks. It took a while to get here, we are incredibly thankful to so many people and organisations who have been the drivers of this success in one way or another. Take a deep breath and enjoy the moment.
In the past, our informal publications featured the perspective of Pantos stakeholders in the form of potential service providers or Pantos holders most of the time. The first group is interested in the conditions and details of providing services for the Pantos network, for instance, staking in the sense of collateral and currency setups or the needs of Pantos software regarding hardware setups. Pantos holders on the other hand are often interested in token use cases to maximise their profits. For example, this means having a functional way of moving assets between blockchains. This transfer functionality could then be made use of again in a profitable way. For instance, the idea of a blockchain domination index requires transparent and freely movable tokens across blockchain borders.
However, there is one group we have not talked that much about yet, which we are nonetheless very keen on onboarding in large quantities to make use of the Pantos network. That group is third-party projects. The first such projects will be tokens that want to enable cross-chain transfers. Projects with more elaborate cross-blockchain aspirations will follow in a later stage. Eventually, Pantos will provide the infrastructure for arbitrary tokens to be moved from one blockchain to another. In the technical parts of today’s project update, we want to talk about how third parties can integrate their token into the Pantos ecosystem to enable smooth cross-blockchain transfers.
The main requirement for a token to be able to participate in the Pantos ecosystem is to implement the Pantos Token interface (IPantosToken). However, most projects, be they wrapped tokens or original work, can and should use our recommended reference implementation PantosBaseToken as the base for their development. For the upcoming Beta testing phase of course, Pantos will be among the tokens to be transferable from one blockchain to another. Additionally, we will also provide wrapping contracts for the native blockchain currencies. Wrapping makes it possible to transfer an asset between blockchains without having to implement any new code into the respective token contract. This can be compared to a voucher asset that can be redeemed anytime for the original asset again. For instance, pBNB can be moved from BSC to the Ethereum blockchain. Converting such wrapped tokens back to their originating form (in the example of pBNB to BNB) for our implementations will only be possible on the originating blockchain (which in this example, is BSC).
Some third-party tokens might have elaborate tokenomics or even renounced contracts, making it hard to do a full conversion. In such cases, wrapped tokens can again be useful where the token is wrapped on the originating blockchain so that it can be transferred using the Pantos network to a destination blockchain. For third-party tokens, it might even make sense to enable unwrapping on the destination blockchain, particularly if a token already has instances on both blockchains. In this case, a precise security analysis is required, as the Pantos ecosystem has no way of gaining insight into third-party token contract details and liquidity conflicts might occur for wrapped tokens then.
The preferred way of integrating Pantos technology into a token contract is by using our reference implementation PantosBaseToken as a starter. For most use cases it will suffice to simply integrate the new functions into the contract and there will be no need to make further changes.
Pantos Cross-Blockchain Transfers
In the following section, we will first detail the procedure of a cross-blockchain transfer making use of the Pantos network. We will then explain the functions from the IPantosToken interface, which is a more than satisfactory candidate to standardise cross-blockchain token transfers in our opinion.
A cross-blockchain transfer in the Pantos ecosystem is designed such that for the user, the only prerequisite is to hold PAN on the source blockchain. The accrued fees are paid in PAN. Otherwise, users would be required to hold the native currencies for blockchains where they want to send Tokens. The blueprint for such a transaction is:
- Pantos service nodes publish their services in the form of transfer bids to the blockchains of the Pantos ecosystem. These bids include maximal transfer amount, transfer fees and guaranteed transfer time.
- The user signs the transaction intent, which includes the sender, recipient and transfer amount, as well as the selection of a transfer bid, with their private key.
- The user then submits this intent to a Pantos service node.
- On the source blockchain, the Pantos service node calls the PantosHub contract, which calls the PantosForwarder contract to verify the intent and forward the burn notice to the token contract.
- As part of the burn verification process on the destination blockchain, the PantosHub is then called again, which in turn calls the PantosForwarder contract to verify intent and burn and to forward the create notification to the token contract.
The question naturally arising here is: why do we need a PantosForwarder contract? The answer to this question is that we have to make sure that the transaction in question actually is legitimate and intended by the sender. In the following paragraphs, we elaborate on this answer with more technical details.
Transfer < Allowance < PantosForwarder
There is always a sender and a recipient represented by addresses for an on-chain token transfer. An address in EVM-based blockchains is usually depicted as the characters “0x” followed by 40 hexadecimal digits (i.e. numbers 0–9 or letters a-f). These either refer to a personal wallet or to a smart contract. Smart contracts and personal wallets are equal in terms of transactions they can initiate.
For a token transfer to happen, it then needs to be submitted to the blockchain. In more detail, it needs to be submitted to the transaction pool, where a miner hopefully picks it up and includes it in an upcoming block. The miners are being paid for every transaction they include in their blocks.
Token transfers can be submitted by the sender, which is the common way to do a transaction, but the ERC20 standard already also allows transfers that are submitted by a third party. In particular, this becomes a necessity if smart contract interactions form part of the transaction. For EVM-based smart contract technology, the calling stack is verifiable only for a single layer. If I call a smart contract function using my personal wallet, then this smart contract knows for sure that I signed the transaction with my private key. This is the case for a common token transfer, where I call the token contract with the transfer(recipient, amount) function. But if I call a smart contract using my personal wallet and this smart contract in the same transaction calls another smart contract, then the second smart contract only knows for sure that the first smart contract called it. This is a security feature, otherwise smart contracts could easily hijack users’ transactions to raid their balances. For instance, trading tokens on decentralised exchanges is a transaction of the second category. To swap one token for another token, the user usually submits a transaction to the DEX contract, which in turn initiates the token transfers, once from the user to the liquidity pool and once from the liquidity pool to the user. For this to happen in a secure way the ERC20 standard makes use of allowances. Allowances can be granted to addresses, but this granting is a blockchain transaction as well and has to be submitted by the owner of the Tokens the allowance is granted for.
Now, for the Pantos use case, we have established that a user should not be required to hold or use native blockchain currencies. Consequently, the ERC20 way of using an allowance does not suffice. And this is where our PantosForwarder comes into play. This contract’s sole purpose is to verify signed user intents. That way a token contract being called by the PantosForwarder can know for sure that the owner of a token really intends to process the transaction. By using the PantosForwarder contract as an intermediary, we can finally have transactions that are paid for in PAN only.
PantosBaseToken Contract
It should be noted here that a third-party token project could choose a forwarder contract which is different to the PantosForwarder. The IPantosToken interface requires only that the token contract has the functions pantosTransfer(), pantosTransferFrom(), pantosTranfserTo() and getPantosForwarder(). Standards in interoperability make security claims easier to verify. This is why we advise the use of the PantosForwarder contract as it will be deployed by us. Special use cases might require custom Forwarder contracts, but in most cases the PantosForwarder is the best candidate for this option.
Given the PantosForwarder contract takes care of transaction intent validation, we now proceed to take a closer look at the other functionality given in the PantosBaseToken contract. The current contract is an approximation to the contract that will be published at the launch of the Beta phase. The approximation here is mostly an omission of keywords and details that are not relevant for the discussion at hand.
2: modifier onlyPantosForwarder()
3: {
4: require(
5: msg.sender == _pantosForwarder,
6: "PantosBaseToken: caller is not the PantosForwarder"
7: );
8: _;
9: }The onlyPantosForwarder() modifier serves to define a keyword. Adding this keyword to function definitions in the smart contract ensures that the function can only be called by the PantosForwarder. Since the PantosForwarder only forwards verified transactions, the functions modified by this modifier can be considered safe in this regard.
11: function pantosTransfer(
12: address sender,
13: address recipient,
14: uint256 amount
15: ) onlyPantosForwarder {
16: _transfer(sender, recipient, amount);
17: }The pantosTransfer() function is very similar to a regular transfer. The difference is that with the onlyPantosForwarder modifier, instead of the sender, this function can only be called by the PantosForwarder. This allows on-chain token transfers where the fee paid by the sender is in PAN only.
19: function pantosTransferFrom(
20: address sender,
21: uint256 amount)
22: ) onlyPantosForwarder
23: {
24: _burn(sender, amount);
25: }
26:
27: function pantosTransferTo(
28: address recipient,
29: uint256 amount
30: ) onlyPantosForwarder
31: {
32: _mint(recipient, amount);
33: }The pantosTransferFrom() and pantosTransferTo() functions again have the onlyPantosForwarder property and represent the counterparts of a cross-chain transaction necessary on each of the blockchains. On the source blockchain pantosTransferFrom() is called, effectively burning the amount from the sender’s balance. Then after the verification of this transaction, pantosTransferTo() is called on the destination blockchain, minting the transferred amount to the recipient’s address.
As can be seen, the PantosBaseToken reference implementation makes use of the almost standardised functions _transfer(), _burn() and _mint(). These functions are part of the majority of all token smart contracts. We do not pose any requirements on the details of these functions, nor on further functionality of the token contract.
In most cases this means that the given PantosBaseToken functions can just be added to any given token contract, to equip the token with Pantos cross-chain functionality, very easily.
Make sure to check our Blog for the second part of this project update, where we will try to take a fresh perspective on the future and talk about our mission.
