Native Token: TEL

Council Proposals TNIP
1

Overview

Native tokens are what blockchain protocols requires users to pay for transaction processing (gas). The native token for Telcoin Network is Telcoin (TEL).

Challenges

Telcoin originated as an ERC-20 token on Ethereum.

The industry is rife with examples of new chains launching their own native tokens, then wrapping them. But other than Polygon and MATIC, there isn’t a good example of an ERC-20 becoming a native token. Polygon’s approach is really complicated, partially because they maintain state with Ethereum via StateSync.

Polygon validators continuously monitor a contract on Ethereum chain called StateSender. Each time a registered contract on Ethereum chain calls this contract, it emits an event. Using this event Polygon validators relay the data to another contract on Polygon chain. This state sync mechanism is used to send data from Ethereum to Polygon.

Additionally, Polygon validators send the transaction hash, namely checkpoint, of each transaction on the PoS chain to Ethereum on a regular basis. You can use this to validate any transaction that took place on Polygon. Once a transaction has been verified to have occurred on the PoS chain, the corresponding action can then be executed on Ethereum.

These two mechanisms can be used together to enable two-way data (state) transfer between Ethereum and Polygon. source

Telcoin Network does not intend to maintain state with Ethereum in the same way. Telcoin Network aims to be an EVM-compatible layer 1 blockchain that uses the ERC-20 Telcoin as its native token. TN is different because core state for the protocol is managed on TN, not Ethereum. The protocol only supports bridging assets, and does not intend to sync state with Ethereum other than passing messages or bridging wrapped tokens.

Bridging

Telcoin already exists on Ethereum, so it must be bridged to Telcoin Network for the network to have access to TEL (the native currency).

Parallelization

It’s possible to optimistically parallelize transactions that do not affect the same state (ie - on-chain programs). However, if bridged Telcoin remains in a smart contract then it becomes nearly impractical to parallelize TEL ↔︎ TEL transfers. As a native token, balances are managed by the node directly so multiple transactions can be processed at the same time which increases transaction throughput. Thus, there is compelling motivation to figure out how to bridge the ERC-20 version of TEL from Ethereum while also using it like ETH (state managed by protocol - not on-chain).

To elaborate, Telcoin and other ERC-20s belong to an address. Ether also belongs to an address. However, when ETH is transferred between accounts, the nodes update the database with that address and a value for Ether. When ERC-20s are transferred, the smart program’s state is updated and the nodes update the database with that address and the storage bytes. State on-chain must be synchronously executed to ensure valid roots are calculated during the state change.

Solution

Telcoin is bridged as an ERC-20 on Ethereum to a wrapped version on Telcoin Network. The wrapped version is not the native token (wTEL), but can easily be converted to the native token TEL.

Axelar

Axelar supports cross-chain transfer of some native tokens via their wrapped ERC-20 versions.

Bridge ERC-20 TEL as ERC-20 wTEL on Telcoin Network

If wTEL on Telcoin Network is bridged, how can users convert it to the native currency TEL without having any TEL for gas?

Axelar supports this through a “Swap Contract”.

The native EVM cross-chain asset transfer feature uses Axelar’s Deposit Service, an ancillary infrastructure contract deployed on all supported EVM chains.

For transactions sending native tokens from an EVM chain, a deposit address is generated by the user or dApp that is set up to receive the native tokens, after which the service kicks in to convert (or “wrap”) the tokens into their ERC-20 equivalent before sending to the users’ specified wallets on the destination chain.

For transactions sending tokens back to their native EVM chain, where users receive native tokens in their wallets, the following flow applies. The funds are first sent from the source chain to a “Swap Contract” on the destination chain. Axelar services then kick in to “unwrap” the tokens before delivering native assets to the intended recipient.

Implementation

Telcoin Network’s TEL could behave like ETH on Ethereum (ie - state managed directly, not through smart program) by bridging the ERC-20 TEL from Ethereum to a wrapped ERC-20 on Telcoin Network then using WETH9 to withdraw the fund to the user’s address.

Axelar’s Interchain Token mechanism would lock/release ERC-20 TEL on Ethereum and mint/burn wrapped TEL (wTEL) on Telcoin Network. Telcoin Network would then support users unwrapping the wTEL to withdraw TEL (on TN) as the native token.

Link to Axelar contract implementation

// @dev This function is used for delegate call by DepositReceiver
// Context: msg.sender == AxelarDepositService, this == DepositReceiver
function receiveAndUnwrapNative(address refundAddress, address recipient) external {
    address wrappedTokenAddress = wrappedToken();
    address refund = IAxelarDepositService(msg.sender).refundToken();

    if (refund != address(0)) {
        if (refundAddress == address(0)) refundAddress = msg.sender;
        _safeTransfer(refund, refundAddress, IERC20(refund).balanceOf(address(this)));
        return;
    }

    uint256 amount = IERC20(wrappedTokenAddress).balanceOf(address(this));

    if (wrappedTokenAddress == address(0)) revert WrappedTokenNotSupported();
    if (amount == 0) revert NothingDeposited();

    // Unwrapping the token into native currency and sending it to the recipient
    IWETH9(wrappedTokenAddress).withdraw(amount);
    (bool sent, ) = recipient.call{ value: amount }('');

    if (!sent) revert NativeTransferFailed();
}

Note: Ensure our implementation of IWETH9 emits a log for bridged TEL. These logs should be used to prove the amount of Telcoin.

Security Considerations

Axelar’s bridge is risky for an early Layer 1 because it provides an easy and efficient escape route for thieves. Ethereum benefited immensely from the fact that it wasn’t bridged “from” anywhere (unlike TN) because after the DAO hack, validators opted to recover funds by forking the network. If a substantial hack took place and Axelar (or any bridge) was a fundamental piece of TN, the affected state would be impossible to rectify without significant changes to both bridged chains. The effect of Axelar’s chain changes would ripple through all other connected ecosystems. It’s impossible to consider forking TN as a realistic solution after an attack unless bridging off TN takes time.

Recoverable Wrapped Tokens

One idea for TN to safeguard the protocol from early exploits tanking TEL is to extend the ERC-20 interface to support asset recovery with the “ERC-20R”. CircleCI has an audited solution for wrapped tokens:

This proposed mechanism revolves around recoverable wrapper tokens. Users can wrap their ERC-20 asset by locking them in the recoverable wrapper token contract in order to receive an equal number of wrapper tokens in return. Wrapping the tokens protects users from thefts, and still maintains most of the utility found in the token’s base form. One core difference, however, is that recoverable wrapper tokens can be recovered back to the sender within a certain time window post-transaction (say, 24 hours). Consequently, each user will have two distinct balances of the token: a settled balance (non-recoverable) and an unsettled balance (recoverable). Only settled tokens may be unwrapped back into their base form.

Building beyond the thesis put forth in the ERC20R paper, we present multiple configuration sets, or ways to implement and design a recoverable wrapper token, each with their own use cases and attributes. For instance, one version is an arbitrated wrapper appropriate for a targeted, designated ecosystem with a trusted governance. Another version offers more of a cancellable send button, where transactions simply take a longer, custom period of time to settle than the chain’s finality. Different configuration sets can still be interoperable with each other, as long as they conform to a shared interface. We provide the IERC20R contract as this interface.

The bridged version of TEL on Telcoin Network would initially be deposited as wTEL then immediately swapped and withdrawn to the user’s account. However, when users initialize a deposit to wTEL they maintain an “unsettled balance” (recoverable) until a certain amount of time has passed.

  • How to handle this if Axelar’s bridge accepts the native token and “wraps” it for the user?
    • When does the token get wrapped? Hopefully the native token is wrapped on the source chain (ie - TN) so we can implement our own recovery solution.

This seems possible with Axelar’s current implementation because the bridge wraps tokens first on the source chain:

// @dev This method is meant to be called directly by user to send native token cross-chain
function sendNative(string calldata destinationChain, string calldata destinationAddress) external payable {
    address wrappedTokenAddress = wrappedToken();
    uint256 amount = msg.value;

    if (amount == 0) revert NothingDeposited();

    // Wrapping the native currency and into WETH-like token
    IWETH9(wrappedTokenAddress).deposit{ value: amount }();
    // Not doing safe approval as gateway will revert anyway if approval fails
    // We expect allowance to always be 0 at this point
    IWETH9(wrappedTokenAddress).approve(gateway, amount);
    // Sending the token trough the gateway
    IAxelarGateway(gateway).sendToken(destinationChain, destinationAddress, wrappedSymbol(), amount);
}

Note: The wTEL deposit and approve methods should work together to cause this to fail. Although it’s not ideal, in the worst case: user tries to send native through bridge and it fails first time. User comes back after recovery period ends and is able to send again. We can mitigate this poor UX by warning users to wrap their own TEL first and wait for the recovery period. We should also try to work with Axelar to support a recoverable wrapped ERC-20s.

Validator Issuance

Validators are issued native TEL on a per block reward. The current TEL issuance is inside a governance safe. TN needs this TEL bridged at genesis if possible. If not possible, then we should consider manual issuance and upgrading the protocol once bridging is complete.

The treasury safe could be owned by SystemCall so the protocol can burn TEL and then mint TEL? Is this a problem if bridging wTEL through Axelar?

2 Likes