Create a Custom Token

You can extend the base implementation of the UTS Token or UTS Connector to accommodate your specific requirements.

To implement your custom token you need to follow some basic rules:

1. You need to install our package

npm i @entangle-labs/uts-contracts

1. Import UTS Base smart contract

import "@entangle-labs/uts-contracts/contracts/ERC20/UTSBase";

UTS Base contract is the main entity in the process of creation UTS Token or UTS Connector. To implement any token or connector you will need to inherit UTS Base smart contract. Simply, it is wrapper around cross-chain communication logic.

To learn more about you can check our examples. There you can also find code with rich technical documentation.

1. Inherit from UTS Base contract. All necessary functions are virtual and you can override them with your own logic.

• The __UTSBase_init function MUST be called before using other functions of the UTSBase contract.

• The _authorizeCall function MUST be overridden to include access restriction to the setRouter and setChainConfig functions.

• The _mintTo function MUST be overridden to implement mint/transfer underlying tokens to receiver to address by _router.

• The _burnFrom function MUST be overridden to implement burn/transferFrom underlying tokens from spender/from address for bridging.

1. Once you have finished editing logic in your implementation, you can proceed to deployment. If you don't have precomputed addresses of your contracts, you can leave initial settings like, chain Ids and chain configs empty.

2. If you didn't provide chain configs through deployment, you can do this after deployment by calling

/**
 * @notice Sets the destination chains settings.
 * @param allowedChainIds chains Ids available for bridging in both directions.
 * @param chainConfigs array of {ChainConfig} settings for provided {allowedChainIds}, containing:
 *        peerAddress: connected {UTSToken} or {UTSConnector} contract address on the destination chain
 *        minGasLimit: the amount of gas required to execute {redeem} function on the destination chain
 *        decimals: connected {peerAddress} decimals on the destination chain
 *        paused: flag indicating whether current contract is paused for sending/receiving messages from the connected {peerAddress}
 *
 * @return success call result.
 */
function setChainConfig(
    uint256[] calldata allowedChainIds,
    ChainConfig[] calldata chainConfigs
) external virtual returns(bool success)

Without setting up this configs in your Token/Connector contracts, your bridge will not work. So, you need to do it on each side of your cluster.

1. After that step your cluster is ready to work.

If you have Connector in your cluster, to bridge to Connector's chain, you need to fill it with tokens, otherwise Connector contract will not have funds to unlock. You can fill it using bridge from Connector's chain, so you will lock some funds on this chain or you can just transfer underlying token to Connector's address. See how to transref liquidity to connector.

You can use advanced logic and let your Connector to mint/burn your tokens, so, you don't need to think about liquidity on Connectors.

If you have multiple Connectors in your cluster, you need to ensure that their balances always have sufficient amounts of underlying token to have a possibility to redeem funds.

We have also Examples section, with clear examples of custom tokens.