Lately, the Zilliqa team has announced a mechanism to incentivize early Zilliqa Ethereum bridge users [1]. The announcement states $ZIL incentives for a limited time when bridging three ERC20 assets - namely WBTC, ETH and USDT.
This vote questions the decision on incentivizing the bridging of USDT to Zilliqa and proposes using USDC instead.
Pros:
USDC is highly regulated and audited on a regular basis while USDT is associated with high regulatory risk
USDC is backed 100% by USD while USDT is partially backed by USD
USDC is most accurately pegged to the USD
USDC is liquid enough for the Zilliqa ecosystem. USDC has a daily volume of >$2B while ZIL volume is currently <$100MM
Cons:
USDT is the most liquid USD pegged stable coin (~$50B daily volume)
USDT has the longer track record
USDT has wide spread adoption
Potential native USDC issuance on the Zilliqa blockchain might introduce confusion about bridged ERC20 USDC and natively issued USDC
One note to be taken into account is that Circle (the issuer of USDC) is contemplating to natively issue USDC on multiple chains. They have already done so for several chains for example Solana, Algorand and more recently Tezos. In case that happens on Zilliqa, having a bridged version will complicate things a bit, add unnecessary engineering work to allow swapping between the two tokens, and create confusion in the community as the network will end up having two versions of the same token. Therefore my vote is for USDT.
Hey Amrit, thank you for providing your thoughts. I acknowledge your concerns and have added your point to the Cons list.
I would argue this is more a general problem. There are already examples of tokens being issued on Zilliqa as well as on Ethereum, most prominently XSGD, XCAD and BOLT. As the bridge promises to allow bridging of any ERC20 asset, this issue needs to be solved anyways in the future.
Thanks! One more thing, other than the tech work that will need to be done, there are also BD issues involved. When a chain already has a wrapped token, this might dissuade the issuer from issuing a native token. As an issuer, I would rather go on a chain where there is no wrapped token already. I am not saying this is absolutely going to be the case but who knows and therefore I am just being prudent.
The method to support the likes of XCAD will require close collaboration with the XCAD team and some sort of token swap for the XCAD community. Expecting the same support from a bigger player like Circle might be too optimistic in my view.
