smartBCH is expected to constantly evolve and innovate. SEPs will be an important part of this continual progression. smartBCH Evolution Proposals aim to help smartBCH evolve appropriately and sustainably towards meeting market demand. There are four SEPs at the time of writing：
● SEP-18：Rejectable token transfers on smartBCH
● SEP-101：Store values with arbitrary length
● SEP-206：Manipulate Native Token as a SEP20 Token
In this article, we will focus on SEP-20 and SEP-206.
First of all, smartBCH is a high-performance, EVM-compatible Bitcoin Cash sidechain. The existing smart contracts and DApps on Ethereum could be migrated to smartBCH easily (at least in theory). To provide even better compatibility, smartBCH will inherit and enhance some of the most important Ethereum EIPs. The first one is SEP-20, which corresponds to EIP-20 (which defines the ERC-20 token standard). For quick reference, we list the ERC-20 token methods in Solidity here:
SEP-20 is fully compatible with EIP-20, plus three optional methods:
EIP-20 has been very important and successful. The ERC-20 token standard played a key role in the past ICO wave and continues to play a pivotal role in the ongoing DeFi revolution. But ERC-20 tokens do have some problems. One such problem is caused by ETH, the Ethereum native token. Because ETH itself is not an ERC-20 token it is difficult to handle both ERC-20 tokens and ETH in smart contracts.
Generally, we can solve the ERC-20/ETH mismatching problem in one of two ways. Take DEX (DeFi’s representative application) as an example:
- Treat ETH specifically. This involves writing smart contract logic mainly against ERC-20 tokens, then squeezing ETH special logic into it. OneSwap uses this strategy. Users benefit from this strategy (better UX, less gas usage, etc), but the contract logic is more complex and thus it is more difficult to discover bugs.
- Use wrapped ETH. This also involves writing smart contract logic mainly against ERC-20 tokens, but supports ETH through wETH. The famous Uniswap uses this strategy. This strategy simplifies smart contract programming at the cost of slightly diminished user-friendliness.
Neither of these two strategies are perfect. To try to solve this problem, smartBCH proposes SEP-206. Because smartBCH doesn’t want to modify EVM, it turns to pre-compiled contracts for help. SEP-206 introduces a pre-compiled contract which provides ERC-20 standard methods for the smartBCH native token (BCH for short). With the help of this pre-compiled contract, BCH and user-published ERC-20 tokens no longer have any differences. We can treat BCH as an ERC-20 token (at special address 100001) in smart contracts, which greatly simplifies code writing.
Through SEP-206 pre-compiled contracts, we can program BCH just like normal ERC-20 tokens. Below is a Truffle testcase to show basic info returned by an SEP-20 pre-compiled contract:
Keep your eyes open for our updates in the next few days. Follow us on social media to get notified when we announce the launch of the smartBCH testnet!
Twitter: https://twitter.com/SmartBCH
Discord: https://discord.gg/uNTRSz6msj
Read.Cash: https://read.cash/@smartbch
Telegram (Community Chat): https://t.me/smartbch_community
Telegram Announcement Channel: https://t.me/smartbch_official
GitHub: https://github.com/smartbch
