Index

• Part 1: BTC
• Part 2: ETH
• Part 3: BNB - Binance Chain

BNB: Binance Chain & Binance Smart Chain

BNB "Binance Coin" is the native token of two separate blockchains, both the Binance Chain and the Binance Smart Chain. It can be natively moved between these two blockchains. In this post I'll describe the Binance Chain. In the next post I'll describe the Binance Smart Chain and how the interop between the two chains works.

ERC-20 Token Origins

The Origins of BNB are slightly complicated, so it deserves its own section in the case of this cryptocurrency.

BNB did not actually have its own blockchain initially. Instead, it was offered as an ERC-20 token on the Ethererum blockchain, sold through an ICO in July 2017 a rate of 1 BNB = 0.15 USD. A total of 100 million BNB were sold to the public for a total funding round of $15 million USD

There were two incentives offered to encourage people to purchase BNB in the ICO:

• A discount when paying trading fees on the Binance exchange using BNB, limited to the next few years. The discount has expired at this point.

• A promise to spend 20% of Binance profits each year doing a buyback of BNB tokens tokens to be burned until only 100 million BNB remain. This promise has since been rescinded.

In addition to the 100 million BNB sold to the public:

• 80 million were given to the Binance founders

• 20 million were sold to private investors

For a total BNB supply of 200 million.

The Binance Chain

The Binance Chain (BC) is a blockchain which was developed and introduced in by Binance for the purpose of powering a specific decentralized exchange (DEX) where users can trade tokens pegged to various cryptocurrencies.

The BC was launched with its genesis block on April 18th 2019. The 200 million BNB tokens started out in address bnb1ultyhpw2p2ktvr68swz56570lgj2rdsadq3ym2 as part of the genesis block. Withdrawals from Binance' website always withdrawal to the Binance chain. The details are unclear but I believe that when ERC-20 tokens were deposited to the centralized exchange they were burned on the Ethereum chain and moved, directly or indirectly from that genesis address to the withdrawing address. This is the mechanism through which the original ERC-20 tokens on the Ethereum chain were migrated over to the Binance chain.

At present, ~16 million ERC-20 BNB remain unmigrated on the Ethereum blockchain.

The Elephant in the Room

The Binance Chain is NOT OPEN SOURCE, it's only shareware: Full and light nodes are published by Binance and available for anyone to run on a specific selection of platforms (currently Mac and standard x86 Linux builds), however the source code for these nodes is NOT available. I also couldn't find any statements by Binance suggesting that they would open source it in the future. This means that I will have to speculate a bit about how the Binance Chain actually works.

What we do know is that it's based on the Tendermint Framework, which is a framework for building blockchains. Basically, Tendermint does all the core blockchain stuff, and you plug in your definition for what transactions contain and how each transaction should modify the blockchain state. In the case of Binance, this amounts to decentralized exchange related transaction types such as one which introduces a new trading pair.

For my analysis I'll assume that the Binance Chain is running a version of Tendermint without and major modifications per their claim: "Binance Chain uses Tendermint BFT consensus and has a dedicated application layer that runs upon it". However, keep in mind that we cannot be exactly sure what behavior the chain actually has! The node software could include a kill-switch which shuts off the Binance Chain instantly for all we know. To be fair, I highly doubt it does include any such kill switch or similarly destructive code, however, things such as the capability to reverse a specific high value fraudulent transaction could very well be present and we wouldn't have any way of knowing about them until Binance chooses to make use of them.

Blockchain Contents

Blocks in the Binance Chain (and any Tendermint based chain... you can see a detailed spec here) consist of the following things:

• A block header containing typical information such as last block hash, timestamp, version, etc.

• A list of transactions, most of which tend to be basic token transfers between accounts, but may also be one of a few dozen specialized transaction types.

• Evidence against misbehaving validators.

• A block footer used in the consensus mechanism.

Each block is limited to a size of 1MB like the Bitcoin blockchain, however blocks are produced much more frequently. There are a few indirect references in the documentation suggesting that the target rate is 3 blocks per second, and this checks out with recent data from the block explorer. Typical blocks only contain a small number of transactions given the very high rate of block production.

The validators produce the blocks in a deterministic round-robin fashion where first node A proposes, then B, then C, etc... until all 11 nodes have had a chance to propose a block and things start over again with node A.

Consensus Model

Consensus is established by a set of 11 validator nodes which propose and vote on blocks to include in the chain. This set of validators was hand-picked by Binance when they set up the BC. The identity of these validators is not known, possibly all of them but likely at least some of them are under the control of Binance.

Binance originally stated that the set of validators "will eventually expand to more members as the Binance blockchain and ecosystem matures" when they introduced the chain in 2019, however, the current set of validators remains the same as the set of validators which was originally specified in the genesis file.

The technical details of the default Tendermint consensus mechanism can be found here however I'm not going to go over them:

• We aren't sure that the default Tendermint consensus mechanism is actually the one being used, Binance may have made changes to it or replaced it entirely.

• Since all of the validators are Binance vetted and the software isn't open source, the consensus mechanism is largely irrelivant anyways as long as it can identify and handle some nodes misbehaving due to hardware issues.

Network Incentives

Unlike most blockchains, the Binance Chain has an entirely fixed fee structure. Each type of transaction has a fixed fee associated with it. When a validator proposes a block containing transactions, they collect the transaction fees associated with the transactions as a reward for running the node. This reward can be split up amongst any arbitrary set of recipient addresses.

Looking at recent usage on the Binance Chain, it seems that the average transaction fees add up to ~0.0005 BNB / block, that is ~100 BNB / day. Assuming Binance controls all, or at least most of the validators, this means that at current prices of ~$500 USD per BNB they earn about $50,000 USD per day, or $20 million USD / year of revenue from running them.

Transaction Types

The most interesting part of the Binance Chain is all the various transaction types. I'm going to go over them in groups here. This very difficulty to find page has a lot of specific information on the transaction types to double check against.

TXN: Transfers

The most basic transaction type on the Binance Chain is a token transfer between accounts. A token transfer specifies a pair of addresses to transfer a specified amount of BNB or any other fungible token between for a fee of 0.000075 BNB. Only a single type of token may be transferred between a single sender and single recipient in a Transfer transaction.

A note on accounts: Accounts on the Binance Chain natively store a balance of not only BNB, but any number of other different fungible tokens (fungible = arbitrarily divisible down to some limit). This is unlike a blockchain such as Ethereum: While the Ethereum blockchain has ERC-20 tokens built on top of it, it only natively stores Ether balances per account, ERC-20 token balances are technically stored in the smart contract of the particular token instead.

For complicated redistributions of tokens, a multi-transfer can also be constructed which sends multiple tokens to multiple addresses. The price of a multi-transfer is 0.000060 BNB per token per address, providing a small discount compared to separate transfer transactions.

TXN: Freezing

A portion of the balance of one of the tokens in an account can be frozen or unfrozen for a cost of 0.001 BNB. While frozen the tokens cannot be used in other transactions.

Note that freezing isn't a security measure in that if you have the private key to make any transactions on the account, you can simply unfreeze the tokens before making whatever malicious transactions you wish. From what I can gather, the purpose of freezing is to prevent accidentally using a portion of the tokens in an unintended way in other transactions while still keeping them in the same address.

TXN: Timelocking

A portion of the balance of any number of the tokens in an account can be time-locked at a cost of 0.002 BNB. It's unclear to me why you can only freeze / unfreeze a single token type at a time, but can timelock multiple types of token in a single timelock transaction but the documentation is clear that that's the way it works. Timelocking tokens prevents them from being spent until after a given UTC timestamp.

Specifically, timelocking is implemented as the tokens being transferred to the special code-controlled address bnb1hn8ym9xht925jkncjpf7lhjnax6z8nv24fv2yq which holds all timelocked tokens. Because of this, a user must submit an explicit "unlock" transaction to move the tokens back to their account after the lock time has elapsed.

Users can also relock tokens to increase their lock time using a relock transaction (almost identical to the initial lock transaction). The user is not required to unlock them first.

TXN: Burning

The Binance Chain actually has an explicit transaction type for destroying ("burning") tokens. On most chains, this is accomplished by sending tokens to visually distinctive address such as 0x00000000 which we can be certain nobody has the private keys for. On the Binance Chain, users can instead explicitly burn any amount of tokens via a burn transaction at a cost of 0.002 per token type.

TXN: Set Account Script

BEP 12 allows setting an account on the BC to have any number out of potentially 64 fixed-function scripts associated with it. At this time, there is only one script, associated with bit 1 of the account flags: When set, it disallows sending of BNB or other tokens to that address without a memo set on the transaction. This can be set on shared payment addresses to prevent users accidentally paying without a memo specifying what customer they are.

A set account script transaction costs 0.2 BNB and updates the account script flags on a single account.

TXN: Issuance, Minting and Ownership Transfer

BEP 2 allows creation of arbitrary tokens other than BNB on the Binance Chain. BNB is the native token of the chain in that it must be used to pay most transaction fees. However, in every other regard, BNB is not special on the Binance Chain: It is only one token type among many.

In order to create one of these other token types, users can send an "Issue" transaction at a cost of 10 BNB specifying:

• The textual name and symbol ("Binance Coin" / "BNB")
• The initial supply. All of the tokens will initially be placed in the address which sent the issue transaction.
• Whether more supply can be minted in the future.

The user who sends this issue transaction will be the "owner" of that token type. As the owner, they can:

• Send a "mint" transaction at a cost of 0.002 BNB to issue additional supply if they enabled minting in the issue transaction.
• Send a "transfer ownership" transaction at a cost of 0.002 BNB to change the owner to a different address.

TXN: Trading Pairs - Proposal, Deposit, and Listing

The purpose of the Binance Chain is to power a decentralized exchange. Here we reach our first transactions related to the decentralized exchange.

The primary purpose of a decentralized exchange is to host a set of trading pairs. The Binance Chain maintains a list of trading pairs. In order to get a trading pair added to this list, there is a non-trivial proposal process which users must go through.

Step 1: User sends a Proposal transaction for 1 BNB

In the proposal transaction the user specifies:

• A base token and a token to trade relative to it.
• A title and description of the proposal.
• Length of the voting period.

Step 2: Users send Deposit transactions for 0.000125 BNB

In order to pass, a proposal must accumulate a total balance of 1000 BNB. Any user can add to this balance by sending a Deposit transaction that references the proposal, as well as an amount of BNB to deposit.

Step 3: Validators send Vote transactions for 0 BNB

In addition to accumulating a 1000 BNB balance, the proposal must be voted on by a quorum of validator nodes via those nodes sending Vote transactions. The details of how the quorum is formed and what happens to the deposited BNB balance of the proposal are way too detailed to go into in this post, but can be found here in the documentation. TL;DR: >50% of validators have to vote yes but with some other conditions and people get back their deposits if the validators do.

Step 4: User sends a List transaction for 200 BNB

Once the proposal has the necessary approvals, the user can send a "list" transaction referencing the proposal which actually creates the trading pair.

TXN: Modify Fixed-Fee Structure

The above proposal process is actually used for modifying the network's fixed fee amounts as well. The proposal transaction has a "type" field on it which can be set to "update fee structure".

Such a modification has been made in the past: The current fee structure is not identical to the one that was present in the genesis file.

TXN: Issue/List Mini/Tiny Tokens

In addition to the main fully fungible tokens, the Binance Chain offers some capability for issuing and listing partially fungible tokens at a lower cost. The goal behind this is to let smaller projects still issue tokens on the Binance Chain without having to pay as much, but with some restrictions on what can be done with the tokens.

The restrictions are:

• Reduced supply: Mini tokens have a max supply of 1 million, and tiny tokens have max supply of 10,000.

• Reduced fungibility: Mini and tiny tokens can only be operated on in amounts >=1.0 tokens. That is, you can only send / freeze / lock / etc at least one token at a time.

• Increased time for trading pairs to match: Mini / tiny token trading pairs are not guaranteed to be matched every single block.

The cost to of an issue transaction for a mini token is 0.6 BNB and the cost for a tiny token is only 0.4 BNB. Additionally, trading pairs can be listed for mini / tiny tokens directly without validator approval at a cost of 1.0 BNB.

TXN: Set Token URI

Normal and mini/tiny tokens on the Binance Chain have a "token URI" associated with them which points to some metadata about the token, such as the textual description and icon which should be displayed for it.

The token URI can be modified at any time by the owner if they send a set token URI transaction at a cost of 0.000075 BNB.

TXN: Pegged tokens via Hash Timer Locked Contract (HTLC)

Another important aspect of the Binance Chain is pegged tokens. That is, tokens on the Binance Chain which are backed by tokens on other blockchains, allowing DEX trading of other tokens not native to the Binance Chain. This is supported by a set of HTLC related transaction types.

It is important to note that the there are some aspects of the pegged token handling that are external to the Binance Chain itself. For instance, Binance publishes a list of "proof of funds" addresses here, which contain the coins that "back" the pegged tokens. However, there is nothing inherent to the Binance Chain protocol that prevents the owner of a given pegged token (the one who created it via the Issue transaction) from minting as many of that token as they want. The onus is is on the users of the pegged token to periodically verify that the amount of tokens in the proof-of-funds address do actually fully back pegged tokens issued on the Binance Chain. Furthermore, those users have no recourse other than simply not holding the pegged token in the case where the owner does mint excess unbacked token supply.

What users can be sure of, is that so long as the owner is running a "deputy" process, there is a fully trustless mechanism to transfer tokens between an external chain and the (pegged version of the token on) the Binance Chain. The deputy process is an external process separate from the validators and other full nodes which watches both chains, and can send transactions on both chains.

I have not been able to find any sources on what the financial incentive for running such a deputy process is. There doesn't appear to be any because the transaction fees associated with the HTLC transactions are collected by the Binance Chain validators, not the deputy process.

I'll go over an illustrative example of how a transfer of tokens from the Binance Chain to an external chain works here. I won't bother going over the reverse but that works in a very similar way.

Step 1: Send a Create Swap Transaction for 0.000075 BNB

The sender picks a random number and keeps it secret. Then sends a Create Swap transaction specifying:

• An amount of a token to send which will be deducted from their account.
• The hash of the random number they picked.
• A recipient address that will be able to claim the sent funds by inputting the (currently unknown to the recipient) random number.
• A lock time, after which the sender will be able to reclaim the funds if they haven't already been claimed by the recipient.

The deputy process will observe this transaction on the Binance Chain, and set things into motion.

Step 2: (Optional) Send a Deposit Swap Transaction for 0.000075 BNB

You can optionally add more tokens behind an existing unclaimed swap using the Deposit Swap transaction. It's unclear what the purpose of this transaction type is, and it hasn't ever been used outside of a single (presumably test) transaction.

Step 3: Deputy replicates the Create Swap transaction

The deputy process observes the Create Swap transaction that was sent on the Binance Chain, and communicates with a smart contract (owned by the token creator) on the receiving chain, locking an equivalent number of coins there behind the same hash for a shorter lock time than the sender's lock time. The fact that this lock time is shorter is very important to the process remaining trustless.

The sender who initiated the transfer should verify that this has taken place before proceeding. If they reveal their secret without verifying this, the operator of the deputy could claim the initially locked tokens using the secret and the sender would have no recourse. If the deputy fails to replicate the lock but the sender does not reveal their secret, the lock on the sending chain will simply expire, at which point the sender's recourse is to simply reclaim the (no longer locked) tokens.

Once the sender does verify that the tokens have been locked on the other chain, things are in fully in their hands:

• If they do nothing for a short time, the lock on the receiving chain will expire first. At this point there is no incentive for either party to do anything other than let the lock on the sending chain expire as well. If the lock ends up expiring in this way, the sender may send a Refund Swap transaction for 0.000075 BNB to reclaim the unclaimed tokens.

• Normally however, they will proceed to...

Step 4: Reveal the secret to claim the tokens on the other chain

The sender now interacts with the smart contract on the other chain, calling the "redeem" function, which takes in the currently secret random number as a parameter. Note that sending the transaction that calls the redeem function will broadcast the secret to the network, at which point it isn't a secret anymore.

Now that the secret number has been revealed both the sender and the deputy are "on the clock" so to speak, and must act within the lock time on the receiving chain:

• The person doing the transfer must ensure that their transaction had a sufficient fee to go through on the receiving chain. Usually the lock time on the receiving chain has enough slop built into it so that the sender can correct things and resend the redeem transaction if the fee was not high enough the first time.

• The deputy must ensure that they send a Claim Swap transaction to the Binance Chain for 0.000075 BNB claiming the tokens there before the lock time expires. Nobody else can "steal" these tokens despite also having the secret, because what address the claimed tokens go to was hardcoded into the initial Create Swap transaction.

If either party takes their sweet time and fails to make these transactions before the lock time expires the counterparty will be able to claim both sides of the swap. Otherwise, the process above has led to a trustless pegged token transfer between chains.

However, let me reiterate what I said above: You're still trusting the pegged token owner on the Binance Chain to not lose control of their secret keys or act maliciously and mint excess pegged token supply, so the whole setup of using pegged tokens still involves some trust.

I should also note that I'm not 100% clear on how the "proof of funds" addresses are supposed to work. Things are clear for the top few pegged tokens, in BTCB and ETH-1C9, however, things get a bit more murky for other pegged tokens. For example, at present:

• The pegged Cardano supply on the Binance Chain is 592,300,000 ADA-9F4

• However, the proof of funds address only contains 200,000,058 ADA

• Even looking at the top holders of pegged Cardano on the Binance Chain / Binance Smart Chain and assuming that the top holder is a Binance controlled liquidity wallet, it's still unclear how to reconcile this difference: I can't find a way to make the numbers add up relatively cleanly.

• The same is true for some of the other pegged tokens as well.

TXN: Placing and Fulfilling Orders

I'm by no means an expert on how exchanges work, so I'm not going to attempt to analyze the trade matching algorithm used by the Binance Chain. I'm only going to talk about the transactions / fees used for trading. The only thing I will say about the matching system is that limit orders are the only supported type of trade on the Binance Chain.

First a note on supported trading pairs. It is hardcoded into the Binance Chain only trading pairs involving BUSD↔_ or BNB↔_ are available on the Binance DEX. That is to say that every trade on the Binance DEX will either include BUSD or BNB on one of the ends of the trade. This is enforced in the List transaction which creates trading pairs.

Sending a New Order transaction to initiate a trade does not cost anything. It locks the tokens that you are attempting to give up until either the trade is completed, or you cancel the trade. The following things are specified when in the new order transaction:

• The order ID. (You technically get to choose this arbitrarily, though there's a standard format)
• What token you wish to trade.
• Whether you're buying or selling.
• The price you are willing to pay.
• What quantity you are attempting to buy or sell.
• How long the order should remain active for. If zero then the order is an immediate-or-cancel order.

Either the order will automatically be completed, and you will be charged a variable fee depending on your account status and what the outcome of the trade was, or you can cancel an open order by sending a Cancel Order transaction for 0.00001 BNB.

When an order is completed, the following things are taken into account when calculating the transaction fee:

• The amount of tokens swapped -- the Binance Chain charges a percentage fee on every trade.
• The activity level of your account. Accounts with higher activity level pay a lower percentage fee.
• The total BNB holdings of the account.
• Whether your fee was paid in BNB or not. Fees for trades can be paid with any token, but fees will be lower when paid with BNB. (the default unless you have insufficient BNB)
• Whether your order was an Immediate or Cancel order or not. Immediate or Cancel orders have higher fees. (Couldn't find any info on what the motivation for that is, if you know please comment!)

Overall, the fees when a trade is filled range from 0.1% to 0.02% of the amount swapped depending on these factors. When an order is not successfully filled, there is a fixed cost:

• Immediate or Cancel Order: 0.000005 BNB
• Other orders: 0.00001 BNB

On-chain Scalability

I've had to scrape together some estimates from various second hand sources for what the chain's scalability is thanks to the lack of publicly compiled info. Unfortunately after far far too much wasted time, I was completely unable to get a Binance Chain full node to run myself (no matter what I attempted the node would start up fine but then sit there doing nothing, not attempting to sync or throwing further errors), so I was unable to build my own data. If anyone has experience running a Binance Chain full node and is interested in helping please contact me so I can make another (hopefully successful) attempt.

Using the numbers from the old Binance Chain full node snapshots in the documentation I extrapolated what the current chain size and growth rate is, but those snapshots stopped getting updated since the Binance Smart Chain launched, so even that data may be a slightly off.

Binance Chain Stats Summary

(Will fill in more info if I can get a full node running and do some analysis)

• At genesis time 200 million BNB existed
• The total BNB supply is decreasing (thanks to Smart Chain gas burns)
• Blocks have an average size of ~300 bytes
• Blocks are being added once every 0.33 seconds
• The block reward is only the transaction fees
• Max on-chain throughput: ? transactions/s
• Typical on-chain throughput: 17 transactions/s
• Transactions can execute Chain specific DEX logic
• Pruned chain: ~850GB increasing by 360GB / year
• Node network requirement: ? Kbit/s bare minimum