Imagine npm bugs for your money. In a sense, that’s what we’re creating with DeFi.

Financial engineering relies heavily on composability, and so does DeFi. This results in an interconnected, intertwined web of primitives. Imagine a SetProtocol Set (a smart contract). It could contain Compound cDAI (another smart contract). cDAI is a claim on DAI (yet another smart contract). To top it off, multi-collateral DAI could be backed by USDC or WBTC, even more smart contracts.

It’s smart contracts all the way down.

If cDAI is frozen, Sets can’t be unbundled. If DAI loses its peg, lenders of other assets in Compound could bear the loss. Everything is affected.

We hear a lot about the magic of composability in DeFi, or “Money Legos.” I want you to remember that it could become “Money House of Cards” in a flash.

This nested risk is called Dependency Risk, which is one of the six risks I cover in this talk at ETHWaterloo2. Other risks include: Smart Contract Risk, Liquidity Risk, Admin Risk, Oracle Risk, and Centralization Risk. I plan to cover these in an upcoming blog post, so now’s a good time for you to subscribe.

Vulnerabilities are inevitable

Exploits are a question of when, not if. This isn’t surprising for an ecosystem as innovative and fast-paced as DeFi, but it’s all the more reason to take risks seriously.

Developers have a finite amount of time to write code, but hackers have an unlimited amount of time to exploit it. In fact, developers are also squeezed by tight deadlines and the fast pace of startups. In a nutshell, it takes developers 3–6 months to ship a protocol, and it takes auditors 3–6 weeks to audit it. Developers make mistakes, auditors miss vulnerabilities, and hackers discover novel exploits. It’s happened before, and it’ll happen again:

Exploits will happen more and more as hackers realize how feasible, lucrative, and unpunished they are. The recent back to back bZx exploits are great examples, given how simple they are at their core. They can be explained in less than 280 characters each:

Daniel Que on Twitter

The recent bZx attacks are fascinating. Here's my simplest explanation: Exploit 1: The attacker used bZx margin to pump the price of wBTC/ETH on Kyber. They then sold the overpriced wBTC. Since they used lenders' funds to pump the price, lenders are left holding the bags.

Daniel Que on Twitter

Exploit 2: The attacker pumped the price of sUSD on Kyber to $2. They deposited sUSD into bZx as collateral and used it to borrow more ETH than they should've been allowed. They then ran away with the borrowed funds with no intention to pay back their underwater loan.

Not bad for a day’s work.

The hacker(s) will be probably never be punished. They were clever to cover their tracks with anonymity tools like tornado.cash, but it looks like that might’ve been unnecessary:

Daniel Que on Twitter

Should exploiting smart contracts be a crime:

Many think that exploiting smart contracts should be allowed. (Whether they’d really let a de-anonymized hacker walk is another question, but the point still stands.) You can’t rob a bank and get away scot-free, but you can rob a DeFi bank and get away scot-free. (Remember folks, the c̶u̶s̶t̶o̶m̶e̶r̶ code is always right.)

You (the bank robber) don’t even need to be ultra technical. You don’t need to be well-capitalized either, thanks to flash loans. The bZx oracle exploit could’ve been conceived and executed by any striped-shirt-wearing-tiptoer, without expert Solidity skills.

This reminds me of another vulnerability discovery in Augur, told by Scott Bigelow:

We ran a HackerOne bounty. […] What was interesting is that somebody read the high-level description of how Augur was supposed to work, didn’t even look at the code, and filed a bug bounty.

Another nugget:

This is very well tested code. But we’re testing the wrong thing.

Smart contract bugs are one thing, economic bugs are entirely different.

Mitigating Risk

So, should you park your life savings in DeFi so you can earn 12%? Probably not, but don’t take my financial advice (which isn’t financial advice by the way). For those who are doing it anyway, you can mitigate risk a couple of ways:

• Require contracts to be audited. To go a step further, verify that the audit was done by a reputable firm. To go a step further, read the audit report yourself. To go a step further, remember that dependency risk means you should also do this with every dependency. And every dependency’s dependencies. And every dependency’s dependencies’ dependency. You can see how hard it is to do this properly.
• Use the test of time. The longer a smart contract sits plump and exposed, available for the world to exploit it, the more likely it is that it won’t be exploited. (See the Lindy effect.) Two caveats: first, some hackers might be like the Witch from Hansel and Gretel, waiting for the kids to fatten up before feasting. Second, the Ethereum VM itself may change with a future hard fork, introducing vulnerabilities that didn’t exist before. Just because code is secure today, doesn’t mean it will be tomorrow.
• DeFiScore: For those who don’t have the time to read audits on their own (basically everyone), you can look to those who do. DeFiScore is a place to start. However, note that Fulcrum (bZx) scored as high as 7.1/10 yet was still exploited.
• DeFi insurance. (Or should I say DeFisurance? 😉 @nemild may be accepting bids for defisurance.com 🙂) Talented teams are working on crypto-native approaches to insurance. One I’m excited about is Opyn, which uses put options for cTokens to insure Compound deposits. Of course, these smart contract systems have their own set of risks that need to be mitigated. That said, I’m looking forward to seeing how things play out.

Conclusion

Dependency risk is often overlooked, so I hope you think back to this article the next time you come across a shiny new DeFi product. It’s inevitable that we’ll see more exploits in the future, and I want us to be more prepared for them. I look forward to seeing risk mitigation improve, and seeing DeFi taken to the masses.

But for now I’ll leave you with this: composability is a double-edged sword.

Thank you for reading! I like Tweeting @dmdque. Sign up here to be notified of future posts. Thanks to Nemil Dalal (@nemild), Regina Cai (@lildex), Jing Wang, Tyson Batistella, Stani Kulechov, and Hart Lambur for the feedback on this article!

A good library lets developers write less code which reduces bugs and saves development time. For blockchain development, libraries are even more impactful because they:

• save gas for end users if they’re optimized
• reduce the amount of code that needs to be audited

We’ve collected various methods in our cryptofin-solidity repo, with an initial focus on array utilities.

We’ll show you how to set it up in less than 10 seconds, then dive into some interesting code that’ll make you feel like you’ve done something productive today!

Quickstart

npm install --save cryptofin-solidity

Use it in a project

Assuming you’re using Truffle or something similar:

import "cryptofin-solidity/contracts/array-utils/AddressArrayUtils.sol";

contract Contract {
  using AddressArrayUtils for address[];

  function containsDeadBeef(address[] memory addresses)
    returns (bool)
  {
    return addresses.contains(address(0xdeadbeef));
  }

}

And that’s it!

For more examples and documentation, see the GitHub.

Into the weeds

Let’s look at some cool and useful functionality.

indexOf and contains

indexOf gives the first index of an element in an array. It returns (uint256, bool) which allows us to implement contains in just two lines using multiple assignment:

(, bool isIn) = indexOf(A, a);  // Ignore uint256 index
return isIn;

map, reduce, filter

These are cool because they use a relatively unknown feature of Solidity: functional programming!

reduce and filter follow similar patterns.

Example:

uint256[] memory nonZeros = array.filter(isNonZero);

union

Using other library functions included in cryptofin-solidity (difference, intersect, and extend), we can very easily compute the union of two sets.

Recall that the union of two sets is:

{A - B} + {A ^ B} + {B - A}

sPopCheap

Let’s break it down:

• s: signifies that this operates on a storage array rather than a memory array (the default)
• pop: removes the element at the given index and returns that element
• cheap: The usual way to implement pop is to delete the element at index and shift all subsequent elements to the left. The gas costs scale O(n), so an alternate algorithm is used to achieve O(1): swap the element at index with the last element, then delete the last element.

sPopCheap doesn’t preserve the array order, and is meant to be used with unordered lists. Another function, sPop preserves order but is more expensive.

We chose to keep the more expensive version as sPop because it behaves as expected for new developers.

argFilter and argGet

argFilter returns the indices that would filter an array, and is inspired by numpy’s argsort. argGet is like numpy’s indexing of arrays notation.

It allows us to work with data with the following structure:

uint256[] ids: [0, 1, 2, 3, 4]

uint256[] ages: [20, 35, 14, 24, 48]

address[] addresses: [
  0x403B5178d38Cf0520F29592c1536061Ef59ff0BD,
  0xF206af3D25f9Fa27b8E68bbA7E6Da953707663D2,
  0xa1949d9c2fd3B13A47B04Ae05353C0A3A7573Eb8,
  0xf163A8D25BF8c09a9Df4e376A50538FeD301e18c,
  0xB5172c7E6B545Fa9Bdd1adCA46fb4e03150C6b0e
]

Let’s say we want to filter out anyone under the age of 21.

function noYoungins(uint256 a) pure returns (bool) {
  return a >= 21;
}

Then,

uint256[] memory indexArray = ages.argFilter(noYoungins);

filteredIDs = ids.argGet(indexArray);
filteredAges = ages.argGet(indexArray);
filteredAddresses = addresses.argGet(indexArray);

Next Steps

We’d love it if you contributed any general code you’ve written that’s suitable for a library! We’ve met some great developers at events like ETHGlobal, so we know you’re out there reading this!

In the near future, we’ll be tackling the following (and would appreciate some help):

• More functionality
• More tests
• Documentation
• Gas analysis
• Gas optimization
• Auto-generated libraries for different types (uint128, uint64, etc.)

We hope this library is useful for your next Solidity project!

Thanks to Nemil Dalal, Mert Çelebi, Graham Kaemmer, and Liam Horne for feedback on drafts!

CryptoFin designed Bskt, a way to create decentralized ERC20 token portfolios. Join our Telegram group for updates.

Improving the Ethereum Developer Ecosystem with Libraries was originally published in CryptoFin on Medium, where people are continuing the conversation by highlighting and responding to this story.

Beyond devastating those who lose funds, these blunders harm the ecosystem as a whole by signaling the immaturity of smart contracts and reinforcing people’s wariness. Better due diligence processes could’ve prevented many of the issues found, saving a ton of headaches, money, and stifled progress.

At CryptoFin, we’ve audited many production-ready Solidity contracts such as Fan Bits (by Rare Bits) and dYdX. We’ve compiled a list of common findings, and issues to watch out for when auditing a contract for a mainnet launch.

We hope this checklist is useful to the community and will raise the bar for contract quality!

View the checklist on GitHub:

cryptofinlabs/audit-checklist

View the PDF checklist here.

CryptoFin created offers smart contract auditing services. Follow us on Twitter, Telegram, or email us at hi@cryptofin.io.

EIP-999 outlines a proposal for a hard fork to recover the $330 million USD of Ether lost in the infamous Parity hack.

The likelihood of this proposal being approved by the Ethereum foundation and community appears very slim. Ethereum hard-forked once before to recover funds from the DAO hack, but this had a negative impact on the ecosystem which took a long time to recover. Many vowed it would be the first and only time.

Ethereum is no longer a nascent technology, and there’s a plethora of alternative blockchain platforms waiting to capitalize on a moment of weakness.

Despite this proposal being just that: a proposal (with weak prospects), everyone seems to be talking about it. I think this is a good time to recall the Law of Triviality:

Everyone can visualize a cheap, simple bicycle shed, so planning one can result in endless discussions because everyone involved wants to add a touch and show personal contribution.

In other words, be aware of how this issue’s coverage is being blown out of proportion. It’s a sensational topic that’s easy to cover and easy to have an opinion about, which is just what I did here!

Problem

GitHub uses linguist to enable language-related features. According to linguist’s maintainers, the .sol file extension is too generic to assign to Solidity.

Solution

Add a .gitattributes file to your repo’s root with the following contents:

*.sol linguist-language=Solidity

Examples:

• .gitattribute file
• .sol file with syntax highlighting working

You may have to wait a while, or push another commit to .sol files for it to take effect.

Conclusion

Since .sol can’t be assigned to Solidity, there’s some discussion around assigning .solidity to Solidity instead. This “consolation prize” is much less than ideal since the current convention has wide usage and deep roots. Changing the convention just to cater to a private git hosting company doesn’t make sense.

Perhaps when Solidity becomes popular enough, .sol will also be automatically classified by linguist.

More in-depth discussion can be found here.

I’m working on CryptoFin, the creators of Bskt and a smart contract auditing firm. You can follow our progress on Telegram.

Bskt is a way to create decentralized token portfolios. A holder can use a single token to hold a number of Ethereum tokens, much like an ETF. Unlike an ETF, you always retain custody of the underlying tokens.

Since Bskt depends directly on ERC20 tokens, we had to ensure they’d behave properly. In an Ethereum contract, a single issue in a deeply nested dependency can break the functionality of the entire client contract. As such, it’s critical to ensure that no ERC20 token functionality can break our Bskt contract.

We hope that our process and lessons will be valuable to other teams that use external contract dependencies in the Ethereum ecosystem.

Before we get started, the token contracts we looked at are: EOS, Tron, VeChain, Icon, Populous, OmiseGO, Binance Coin, DigixDAO, 0x, Augur, Waltonchain, Bytom, Status, IOStoken, Zilliqa, Kyber Network, Basic Attention Token, Aelf, Qash, AdEx, and Maker.

What to look for

Our primary focus was to ensure that ERC20 token contracts would work well with our Bskt contract. Bskt’s two primary functions are:

• create: Surrender one or many different underlying ERC20 tokens for a Bskt token (source code)
• redeem: Surrender Bskt tokens for the relevant ERC20 tokens (source code)

For our purposes, we focused on these key ERC20 methods that Bskt’s two methods interacts with:

• transfer
• approve
• transferFrom

Our approach

Each contract was assessed by two separate teams of developers. We also incentivized our team based on issues found that the other team didn’t find.

Nearly a third of the time developing Bskt was spent auditing external dependencies. We highly encourage other Ethereum dev teams to be aware of the dangers in external dependencies. Unlike software development in most systems, it’s critical to read the implementation of deployed contracts you depend on — not just the interface.

Key findings

Nearly half of the top 20 projects can have their token transfers completely frozen by an owner

Pausing

Though many think of Ethereum contracts as fully decentralized, nearly half of the top 20 projects can have their token transfers completely frozen by an owner (a single key or a multisig contract). Pausing can be valuable for future upgrades, swaps, and disaster mitigation but also leads to new risks.

The pausable tokens we reviewed are: EOS, Tron, Icon, OmiseGo, Augur, Status, Aelf, Qash, and Maker. Some of the tokens implement pausing largely because they’re moving to their own blockchain, and want to freeze their ERC20 tokens.

The ability to pause can lead to two issues:

• Trust: It requires all users to trust the party in charge of the key, reducing the degree of decentralization in the contract.
• Security risk: It requires the key holder(s) to secure the private key. An attacker (i.e., a disgruntled employee) could hold the network hostage and demand a ransom by freezing transfers, or short the token which is sure to drop in value.

A naive implementation of our Bskt contract that doesn’t handle pausing would fail on the redemption of all tokens, if a single token was paused.

Instead, our contract lets you skip a paused token — removing the risk that a single ERC20 token pause could hold the other tokens hostage.

For new ERC20 token creators, our recommendation is to implement pausing conservatively, and to consider splitting privileges into separate owner addresses, similar to what Unix does with user groups.

Unverified code

Verifying source code on Etherscan is optional, but is something most popular token contract dev teams have done.

Only one team from our assessment, Icon, did not post their code. The contract hosted in their GitHub was reviewed instead, but without verification there’s no way to guarantee it matches the code in the blockchain (and we tried a number of combinations).

We opened a GitHub issue (which you should upvote) requesting them to verify their contract with Etherscan. In general, we highly recommend posting your code on Etherscan (not just Github) as it:

• Makes it easy for other to build on top of your contract,
• Ensures that many eyes can look at your contract (and not publishing — i.e., security by obscurity — is a poor method to ensure security).

ERC20 “Standard”

Some of the most popular Ethereum tokens were created early in Ethereum’s life before ERC20 was finalized, and so do not fully comply with ERC20 behavior:

• Golem’s GNT doesn’t implement approve, making it technically not an ERC20 token, and incompatible with Bskt.
• Several contracts throw on transfers of 0 tokens rather than logging the amount.

Additionally, the idea of an ERC20 “standard” is amorphous compared to other standards in technology (i.e., IETF standards). For example, the standard specifies “should” rather than “must” for some critical behaviors (discussion here).

Usability vs. Security

The zero race condition approval attack is can occur when you change your approve amount to a given contract. For example, you want to reduce the amount approved from 1 ETH to 0.5 ETH. The approved contract can race to transfer the money you initially approved (the 1 ETH) and then also spend the money you just approved (0.5 ETH), rather than being restricted to the updated value.

Some tokens’ approve methods enforce behavior to fix the zero race condition approval attack.

While enforcing better security, it reduces usability since two transactions are required to change the approved amount. The first transaction requires zeroing the approve balance, and then setting the approve balance to the new value.

(While this doesn’t affect our contract, it does affect our soon-to-be-released dapp, which needs to handle both types of contracts.)

Burning by Sending to 0x0

Some tokens (like Tron) implement burning by sending tokens to address 0x0, rather than reducing the totalSupply state variable. While both approaches work, the lack of standardization makes it harder to determine the circulating supply.

Miscellaneous

There were a few final specific notes for certain contracts:

• Binance Coin allows users to freeze their own funds, which then requires them to unfreeze it before transferring. Note that this is different from pausing transfers as discussed, which BNB doesn’t do. This is covered in more depth here.
• Contracts like AdEx’s handle the short address attack vector with a modifier. The consensus instead is that it should be handled by client libraries, such as web3.js.

Conclusion

Auditing downstream contracts when developing protocols is easy to overlook for many software engineers, especially when they are used to more popular software ecosystems like npm.

For experienced software engineers new to Solidity, we encourage a different mindset more akin to a hardware engineer (where failure is costly and reprogramming is hard). This mindset requires you to understand all dependencies in depth, as well as their interaction effects.

Performing this audit was a critical milestone for us before releasing Bskt.

About CryptoFin

CryptoFin has designed Bskt, a way to create decentralized ERC20 token portfolios. If you ever have your own questions about code correctness in blockchain contracts, drop us a note. You can also join our Telegram group.

Thanks to Nemil for reviewing and editing!

Our whitepaper provides full details and you can create your own bskt using our source code.

As interest in cryptocurrencies has grown, thousand of tokens have been launched on the Ethereum blockchain. Our Ethereum contract allows anyone to compose any number of different ERC20 tokens into a single token. Gone are the days you have manage tens — or hundreds — of Ethereum tokens.

Much like an ETF, Bskt makes it convenient and cost-effective to hold a number of ERC20 tokens, while in actuality maintaining ownership of a single token.

Unlike traditional ETFs, users maintain custody of the underlying assets. Anyone can convert their Bskt tokens back into the underlying tokens without any external approval. Bskts also work with any Ethereum smart contract — and the holdings are fully transparent.

The ERC20-compliant Bskt contract we’re releasing allows one to:

• instantiate a custom Bskt with both pre-specified underlying tokens and a selected proportion,
• create Bskt tokens in exchange for surrendering underlying tokens,
• redeem Bskt tokens for the underlying tokens, and
• transfer the ownership of Bskt tokens

Visually, a Bskt can be created and redeemed in the following way:

While some exchanges are creating their own cryptocurrency indexes, they’re not tradeable. A Bskt token can be traded on exchanges across the world, providing large liquidity and an accepted standard token across exchanges. In the future, we’ll provide technical capabilities for rebalancing — and extracting tokens that are migrating off the Ethereum blockchain.

CryptoFin will be launching the first official Bskt instance soon. It will track some of the top ERC20 tokens, weighted by market cap. Sign up to be notified when we launch.

The CryptoFin team does not sell tokens, and to create your own token you must buy the underlying tokens — and make the relevant Ethereum call to bundle them. All code is provided AS IS — please use at your own discretion.

If you’re interested in using Bskt for your own purposes, please get in touch. Or join our Telegram group.

See the Bskt whitepaper and the source code.

Announcing Bskt, a smart contract for creating decentralized token portfolios was originally published in CryptoFin on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the current bull market these dividends may appear negligible compared to value gained by simply holding a coin. However they add up to something substantial over time so like any form of investing: the earlier you start, the better.

Lending

Poloniex runs a peer-to-peer margin trading system in which users are able to trade with funds borrowed by other users. There’s no additional risk to the lender due to margin call mechanisms. This passes all of the risk onto the borrower by liquidating their funds before they’re unable to pay back their debt.

By lending you’ll collect an interest rate on a periodic basis. The rate and duration of a loan is determined by an order book, giving you some control over how much interest you’ll earn.

I find lending exciting since it allows you to generate passive income from coins that otherwise wouldn’t.

Notes:

• The market rate fluctuates with demand which tends to spike when volatility is high. Typical rates range from 0.0001% to 0.1% per 2 days. When prices are volatile, rates can go up a lot. Poloniex has more info here, and I highly recommended this informative blog post.
• Poloniex takes a 15% cut of the fees, which is absolutely deserved given the work involved in implementing this feature.

Estimated annual return: 2%

Proof of Stake mining

Proof of Stake (PoS) secures the network similarly to how Proof of Work does. It’s essentially a virtual Proof of Work, with many benefits.

Ethereum

Ethereum will soon be moving to Proof of Stake mining with the Casper project.

Ethereum’s PoS will only be profitable if enough Ether is being staked due to gas costs. Parameters have not yet been finalized, but it’s been suggested by Vitalik that this figure could be 1000 to 4000 ETH. This is too much for most people, but staking pools like Rocketpool exist to overcome this.

Estimated annual return: TBD

Neo

Holding Neo in the Neon wallet will automatically produce Gas. Note that the Gas reward will decrease over time, eventually converging to zero. Only some exchanges will credit Gas to your account, like Binance which does it on a monthly basis.

Use neotogas to calculate how much Gas you’ll receive.

Estimated annual return: 7%

Masternodes

Masternodes were pioneered by Dash and have since been copied by other projects. Masternodes are special nodes which provide additional services to the network.

In general Masternodes work by running the special node software, and require some number of coins to be eligible.

Dash

Dash Masternodes primarily InstantSend and PrivateSend as a service to the network. To run a Masternode, 1000 DASH is required. Though it was feasible to accumulate this amount a year ago, it’s now much too expensive for a typical investor.

Masternode.me provides a masternode hosting service for those lucky enough to have 1000 Dash. They also provide a pooling service in which a Masternode is divided into 40 shares for 25 DASH each.

Check payout stats on dash-news.

Estimated annual return: 7%

Miscellaneous

Stellar

Stellar has an inflation mechanism that you can take advantage of to increase your holdings.

The Stellar distributed network has a built-in, fixed, nominal inflation mechanism. New lumens are added to the network at the rate of 1% each year. Each week, the protocol distributes these lumens to any account that gets over .05% of the “votes” from other accounts in the network.
(source)

The threshold for reaching that .05% of the votes is high considering the market cap of Stellar. This means you either have to be a whale, or join a pool. Here are some pools you can choose from:

• futuretense
• xlmpool

These pools require you to provide your private key, so be weary. Decide whether or not to trust them with your funds by doing your own research.

Estimated annual return: 1%

Airdrops

Airdrops are slightly different but worth mentioning. Some distributed ledger projects distribute their tokens based on the current distribution of another Blockchain, usually Ethereum.

If you manage your private keys, you can claim free tokens (though sometimes there’s a bounty task involved.)

The most difficult part about this is staying up to date on which airdrops are happening.

Estimated annual return: N/A

Hard Forks

Hardforks went from being a dreaded contentious event to an anticipated event once people realized they were getting free money. The first major hard fork was Ethereum Classic.

Ideally you control your private keys, since exchanges and wallets are slow to credit accounts with forked currencies, if ever.

Once again, it’s difficult keeping track of which projects have significant upcoming hard forks.

Estimated annual return: N/A

Conclusion

The best cryptocurrencies to use for passive income today are Neo and Dash. Lending is notable since it allows you to earn from coins you were planning to hold anyway, and don’t natively provide passive income.

Be aware that some of these payouts are similar to dividends, and are subject to being regulated more strictly in the future. Earning rewards as a result of work such as running a masternode are more legally defensible.

With the plethora of coins, I’ve undoubtedly omitted some. While I actively avoided untrustworthy projects, there are certainly many I simply don’t know about. Leave a comment if you think I should include more.

I’m working on some awesome Blockchain stuff, launching soon. Follow me on Medium and Twitter to stay in the loop.

It’s a checksum, meant to provide some validation that it’s a valid Ethereum address. Other crypto projects like Bitcoin employ a a checksum as additional bytes in the address, which has been vital for preventing funds from being accidentally locked forever. Ethereum has millions (USD) worth of Ether and tokens locked due to unintentional transactions.

The checksum helps prevent these mistakes since clients can (and should) validate that the checksum is correct.

The checksum algorithm works by capitalizing some alphabetical hex (abcdef) characters based on a heuristic. If the 4·ith bit of the hash of the lowercase hexadecimal address is 1.

For example, the address 0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed is a valid checksummed address.

The checksum algorithm is laid out in full detail here.

Here’s another good explanation from a Reddit comment.

I’m working on some awesome Blockchain stuff, launching soon. Follow me on Medium and Twitter to stay in the loop.

Binance implements freeze and unfreeze methods on its BNB token contract. Now, it’s not what you may think it is — it doesn’t allow Binance to freeze users’ balances. Instead, it allows any user to freeze and unfreeze their own funds.

The freeze feature is implemented with the not-so-well-named freezeOf state variable. We can check frozen balances by querying it. The following screenshot shows the BNB token owner’s regular balance and frozen balance, denominated in BNB base units.

It shows that the team is holding around 730 million USD worth of BNB in their regular balance, and around 580 million USD worth in their frozen balance.

The reason for this feature perplexes me. I couldn’t find any mention of it in their whitepaper nor any answers from online searches. (Searches for “binance” and “freeze” variations bring up results about closed or frozen exchange accounts.)

Possible use cases I’ve considered are:

• Security: It’s an extra step (though a minor one) for someone to withdraw the funds.
• Obfuscation: An account can “hide” their balance from those who don’t know about this feature. At the very least it makes it more work to query.

Neither of these are convincing to me. If you have a better suggestion, what is it?

Reddit user Jane-Delavega has cleared this up in their comment.

From the whitepaper:

BNB Vesting Plan for the Team
Initial release: 20% (16MM)
After 1 year: 20% (16MM)
After 2 year: 20% (16MM)
After 3 year: 20% (16MM)
After 4 year: 20% (16MM)

The frozen 64m BNB is the team allocation that is still vesting.

In July another 16m BNB of the team allocation will be unfrozen. The trading fee with BNB discount will also increase from 0.050% to 0.075% in July. All else being equal, this will increase Binance’s profit from trading fees. They use 20% of their profit to buyback & burn BNB until 100m BNB is removed from the circulating supply.

Mystery solved!

I’m working on some awesome Blockchain stuff, launching soon. Follow me on Medium and Twitter to stay in the loop.