Co-founder and Product Architect at Bancor

Jun 20

Response to “Bancor is Flawed”

Below you’ll find a line by line response from the Bancor team to the “Bancor is Flawed” article by Professor Emin Gün Sirer. We’d like to start with a short introduction and a plea to the industry for everyone’s sake: In order to encourage innovation, and in the hopes of building a world better than the one we’ve inherited, we must adopt healthier standards for debate and criticism than what we’ve seen here. We must hold ourselves to a higher standard than the “fake news” and soundbite culture we’ve come from. We must present clear and specific research for our opinions in order to contextualize them. We must assume good faith unless we have actively reached out to those we levy claims against and have been met with none or uncooperative response. We, as an industry, deserve this, because our mission to reimagine the systems which facilitate the collaboration of free humans is no less than critical. Our analysis shouldn’t be either.

We at Bancor will be the first to say we welcome all opinions. We have eagerly solicited feedback on our proposals via every channel available to us. We have hosted numerous AMAs run for hours until every question was answered. We have made our entire team available by direct personal message to our cell phones and answered every request, no matter how repetitive or hostile. We only ban users from our groups who employ hate speech towards others, and allow thousands to critique our work freely, allowing their concerns to guide us to both where our product and messaging need strengthening. The article below was published with zero effort that we are aware of to discuss the points raised, and employs questionable ethics in both it’s assumptions and inflammatory language. We welcome the opportunity it has given us to make this formal request of the community to do and demand better as we move into the future we design.

As mainstream media picks up on this article as “evidence” that the entire blockchain space is a “ponzi scheme”, we as an industry risk major setbacks and real damage to the progress we have made by airing our differences in this alarmist manner. It is our collective responsibility to reject FUD as a way of discourse and to encourage respectful, thoughtful and direct debate. Those who defend the ways of the past will use our disagreements to divide and limit us, and we must, together, make it clear that while we may hold different coins we represent the same values: freedom, integrity and community.

Bancor just did their Initial Coin Offering (ICO) last week and raised a record $144M within a few hours. They now hold the record for the biggest crowd-funding, ever, in the history of mankind.

At time of raise its was $153M within 2:25, this has been covered widely including a formal statement on our blog.

We don’t want to dwell too much on what this illustrates about the current ICO craze. It’s a fact that raising that much cash through a standard VC process would require a credible team, multiple rounds of funding, with much due diligence and milestones along the way. None of that happened here — Bancor went from appearing on the scene 5 months ago to raising 9-digits cash with no demonstration that their scheme actually works.

We will leave it to readers to judge whether the credentials of the team members are “credible”. Your analysis is especially surprising given that the third member on the list is Bernard Lietaer, who literally wrote the book(s) on money in his 40-years of documented private and public sector experience. The rest of the team has been presenting their backgrounds and our product in blockchain pitch competitions, conferences and meetups all over the world, posting footage, including live Q&As, directly to our site.

We did not “appear on the scene” 5 months ago. We’ve been on the scene since May 2011 (and venture-backed consumer software entrepreneurs for many years before that), when we first learned about Bitcoin. We’ve logged over 1,000,000 transactions in custom currencies that we created on our own, off chain platform at our previous company, Appcoin. There was no Ethereum back then, not even Mastercoin (Omni), so we built our own system (and hosted the Mastercoin management and hackathons in our office), because we were eager to learn how real community members would use new tokens in order to trade real products and services with each other. We believe that user-generated currencies propose a tremendous potential opportunity for human organization and engaged heavily with the local and international crypto-community (who all know us, including but not limited to our advisors, also posted on site, who are thought and industry leaders in their respective domains.) We ran pilots for community currencies in Ithaca, Berkeley and Cornell.

We also take issue with the insinuation that Venture Capital is the correct (or even a better) standard for evaluating and funding projects in this space. We say this as serial entrepreneurs who have been both funded by premier venture funds (Accel, Pitango and others) and rejected by them (too many to name) as well as worked for and with them (Trinity Ventures, Founders Fund) and having watched countless projects raise massive war chests for worthy projects as well as for other reasons, such as inside baseball, bandwagoning, inadequate due diligence, etc. We count many Venture Capitalists as friends and collaborators and they play an important role in the ecosystem. However, as an industry, they do this with varying degrees of success and very limited transparency, and also manage portfolios of investments that are intended to produce few (if any) unicorns for many failures. They also count their expected ROI in traditional currencies, whereas the Bancor project aims to create new types of tokens which are in themselves valuable. This type of project is uniquely tailored to support of the crowd which stands to benefit most from its success. And to insinuate that Bancor has undergone no due diligence is to ignore the fact that top-tier firms have been willing to publically announce their support (Draper Associates, BlockChain Capital) and the rigorous and public scrutiny that every word in our blog posts, messages, presentations and materials, as well as every line of code (not to mention every movement of ETH in our accounts) is subject to every day, around the clock, by tens of thousands of followers around the world. We have, humbly, never submitted ourselves to this level of public scrutiny in our decades of being entrusted with capital to execute software projects. It is exhausting and often frustrating and even hurtful, but we undergo this willingly in order to support the movement towards more open dialogue and real accountability that the decentralization community is committed to. It’s not easy, but it’s important. And it’s certainly more oversight than we feel we’ve ever had in our careers as entrepreneurs.

Bancor uses lots of mumbo jumbo terminology.

Bancor addresses the “double coincidence of wants” problem in economics through an “asynchronous price discovery” mechanism that blah blah blah buzzwords blah and more buzzwords. Half of these buzzwords aren’t even real. “Asynchronous price discovery” is a franken-word they made up. It borrows asynchronous from distributed systems and “price discovery” from economics. The crowds eat this stuff up, but in reality, it’s just a giant red flag — there’s no content here.

It is hard to reconcile claims like “mumbo jumbo” and “blah blah blah” with legitimate critique. This language is more hyped than what we consider (with which you take issue) to be relevant terminology for a new methodology we are proposing. Here’s how we think of these terms:

Googling of “asynchronous” yields:

“(of two or more objects or events) not existing or happening at the same time.”

The core of the price discovery process in classic exchanges is at the moment when two opposite wants (orders), existing at the same time — are matched and result in a trade. This synchronized action can be compared to talking on the phone where both sides need to be on the line at the same time. Asynchronous communication is like text messaging where one can write now, and others can read and write later.

With Bancor, there is no need for two opposite wants to exist at the same time in order for the price discovery (through actual trading) to function. This is an exact case of “asynchronous”, at least according to the google definition of that word.

It is also worth noting that no one talked about communication as “synchronous” until the advent of “asynchronous” communication. Similarly with asset exchange, until now there has been no “asynchronous” model to speak of. This term is not a “franken-word”, but a new concept.

Let’s move on, for it’s possible to have a good idea underneath fluffy marketing.

We sincerely do not think our marketing is “fluffy”. We have spent near 0 dollars on PR or advertising, have no marketing personnel on our team beyond the founders, and created only one 3 minute video, released 1 day prior to the TGE, due to overwhelming requests from our community that we simplify the message for more to understand it. One of the most frequent criticisms we get is that the white paper and materials are far too technical, economic and formula driven for the casual consumer to appreciate.

The core problem they want to address, “Double Coincidence of Wants” is not a real problem.

“Double coincidence of wants” is a real problem in economics today in the sense that the “itsy bitsy spider” problem is a real problem in zoology — that is, it’s something one might learn in grade school, and it’s completely irrelevant in the real world.

We are unfamiliar with the “itsy bitsy spider” problem in zoology, so cannot comment on this comparison. We can only assume this comment is inflammatory rather than serious in nature.

Disregarding this problem is a fundamental mistake. The DCoW problem has a clear effect in asset trading and it has a name: “Liquidity Risk”. The only way liquidity risk may exist is when it becomes a rare event to find other parties with opposite wants to trade with. Naturally, price risk still remains, however, low price provides a potential opportunity, while illiquidity results in a disconnection from the larger network of value transfer.

Our thinking here is that people invented money to solve the DCoW problem in barter, making trade asynchronous, more efficient and predictable. We wanted to create “money for money”, making asset exchange more efficient and predictable as well.

To be fair, you might indeed come to the market with two rabbits one day and I might come to the market with two chickens on the same day. I might also have an aversion to rabbit meat and a family history of mal de caribou. We would then be unable to conduct a trade.

In reality, this never happens, because…

One can always use ether as a medium of exchange.

You have just explained how “currency” is a technology that solves the DCoW problem for barter. Our whitepaper explains how the Bancor protocol solves the DCoW problem for asset trading — where transactions today still rely on matching two parties with opposite wants. Furthermore, our entire project aims to provide additional functionality beyond ETH, and create, as they did (and benefiting from their infrastructure, and they from our Dapp’s activity) a valuable token in its own right. Should all token development stop now that we have ETH? Should ETH never have been created because we had BTC? Should BTC never have been created when the USD was already a liquid medium of exchange?

There already exists a common currency through which we can trade. It’s called ether, and we can use it no matter which token pairs we want to trade, because those very tokens are, by definition, implemented on top of Ethereum and were purchased with ether in the first place.

To claim that Ethereum based “tokens” were purchased with Ether in the first place is factually wrong. Our ERC20 bounty tokens weren’t purchased with Ether, and are quite valuable now. And to claim that the relevant token pairs people may want to trade are only those implemented on top of Ethereum, is also wrong. The “Hearts” tokens we operated back in 2013 that were used in > 1000 transactions a day in a single community and were definitely not purchased with Ether while having real value to those who accepted them for products and services. This claim seems so detached from reality that we wonder whether we understood your intention correctly.

Using BNT tokens is like stepping into a kid’s swimming pool, placed in an ocean.

You could say the same thing about Ether. The reality is that the team, contributors, early believers and adopters of Ethereum were rewarded for their risk and efforts due to the fact they did not choose to build smart contracts using the existing Bitcoin as their currency. These are the basic economic principles and incentive structures of cryptocurrencies. Those who are first to bet (with their time, money, processing power or other resources) on a new emerging solution, are financially rewarded if the solution gains greater popularity and usage. These dynamics do not seem apparent to the writer(s). This is one of the most exciting things to us about the emerging protocol token space, where developers and contributors can take part in future value created for all, if it succeeds.

The entire point of the underlying currency, ether, is to serve as the medium of exchange for the diverse assets built on top.

That is clearly not how the Ethereum foundation sees it. Maker is a good example of why a more stable currency could potentially serve better as a medium of exchange (itself being collateralized by Ether). BNT is similar to that in some respects, and the motivation to use it is for the group to create a network effect for itself.

Sure, we can always layer BNT on top, and use BNT underneath the new Bancor-based tokens, but there would be little point in doing so besides creating a money flow for the people behind Bancor. For every coin they design that uses Bancor, we can design a more efficient version that doesn’t use Bancor.

In short, the BNT tokens are for show. They are not necessary.

Similarly to other cryptocurrency ecosystems, such as Ethereum itself, and as noted previously, there are actually two other important groups to which “money flow” is “created”, as you put it, besides the “people behind Bancor”. The first group are the contributors who funded or otherwise supported the product’s development, marketing and operations. The second group are the early adopters of the new ecosystem, that are willingly experiencing its growth pains. All three groups are equally critical for the success of a network, and in this model, all three groups will benefit from Bancor’s growth.

BNT is the first smart token, and using it as a reserve makes the same economic sense as it did to use Ether, rather than Bitcoin, to power a smart contract blockchain. Tokens are used in all of these examples for mass-collaboration between the sponsors, supporters, developers and users toward a common goal they are all incentivized to achieve. In addition, as the value increases, these groups share in the appreciation, creating a novel, fair and inclusive model for splitting the upside of a successful project.

BNTs will be the default reserve token, and smart tokens which use it as a reserve (directly or indirectly), will get benefits within the network, for example, such as Bancor sponsoring their gas consumption whereas non BNT smart tokens may pay for their own gas, etc.

Obviously, copycat networks can always be created, but the brief history of cryptocurrencies demonstrate a clear advantage to the first cryptocurrency in every new category lead by capable teams.

In short, the BNT tokens are not for show. This is the first network token to serve a new ecosystem of smart tokens that utilize the Bancor protocol to create intrinsic liquidity through user-configured reserves.

Having said all that, Ether holders also benefit from Bancor’s success, as ETH is used to purchase BNT. An increased demand for BNT will have a positive effect on ETH prices as well.

We have been very clear in our use of funds as to what portion of BNT is allocated for the team, present and future, and its corresponding vesting schedule. The implication here that the team is the only one standing to benefit from the creation and development of BNT couldn’t be further from the truth.

Bancor is essentially a central bank strategy for automatically setting a dynamic peg for new coins.

Behind the hype, Bancor comes down to a very simple idea: it’s a smart contract that automatically provides a buy and sell price for a new coin. This is known as a market maker.

Yes, we believe the power of the Bancor protocol also lies in its simplicity. However, the concept of an automated market maker integrated into a cryptocurrency which can issue and destroy tokens while also being traded on any online exchange — is a novel concept, and should be recognized as such.

Let’s suppose that you decide to create your own coin called X. You hype up the X ICO, sell $100M of X, and decide to back it with $10M of BNT. This is your reserve.

What Bancor proposes to do is to create a market for your coins by automatically buying and selling them for prices that would preserve the ratio of your reserve to the total supply. That is, depending on how much reserve the contract has outstanding, it will automatically offer a price for the X tokens. If the reserves are, say, $12M BNT, then it will offer to buy back X coins for higher prices, to bring the reserve fraction back in line to the usual level. If the reserves are low, it will offer lower prices. So you can always buy or sell into the contract, even if there is no one else to buy or sell to.

That’s it. That’s the whole idea.

That is not accurate. The “reserve fraction” (CRR) is not “brought back in line to the usual level” as you state. The price is calculated according to the current reserve and supply so the reserve cannot mathematically be “out of line” by definition. We considered a method of dynamic realignment (as your text seems to describe) years ago, however we found the deterministic CRR based model to be significantly more robust and less gameable, due to its simplicity.

It’s only 40 lines of code.

Now, there is nothing wrong with raising $3.5M per line of code, if indeed there is a certain technical advantage that those lines of code possess.

You continue to ignore the 60K+ lines of code which power our live-on-mainnet bounty program and public alpha where users can create smart tokens by answering a few questions via a chatbot and utilize a comprehensive webapp compatible with desktop and mobile browsers.

After 20 years of software development across different startups, we simply don’t share your view that this work is worthless. There are very few Ethereum apps that are as easy to use, and just like Coinbase made Bitcoin/Ether accessible to millions, we plan to do the same for user-generated tokens (at first on Ethereum), and we believe that the prospects of that use-case are incredibly exciting.

Also, Martin Koppelmann, the CEO of Gnosis, tweeted a reply to you that their core smart contract codebase is not much bigger, and that it is a good practice to keep the smart contract functionality to a minimum. We do not agree with your method of measuring the value of a protocol by the number of lines in the Solidity code of the smart contract as valid or rational. It would absurdly suggest that solutions such as Coinbase do not add value to the Bitcoin protocol. Or that enormous code bases are somehow inherently more valuable. We encourage you to try out the demo of the product which has won awards at every blockchain competition it was demonstrated at around the world. The idea here is to make token creation as simple as uploading a video to YouTube. We think this is a profound opportunity for the crowd to participate in value creation, beyond content.

Everything Bancor can do for you on chain, you can do by yourself off chain.

You yourself could easily have held that $10M in reserve, and you could have intervened in the market at your leisure. If you wanted to, you could follow the exact same algorithm as Bancor and achieve the exact same results. There is no value to be had from using Bancor.

Let us repeat that: in terms of controlling the price of the X token, there is absolutely nothing to be gained by using the fixed Bancor strategy. Whatever equilibrium price Bancor would achieve for you through its on chain management, you could have achieved while managing the reserve yourself, off chain.

This statement is simply erroneous. The Bancor protocol issues tokens in exchange for the reserve token and destroys tokens when paying out reserve tokens, which is what enables the reserve to grow and shrink relative to the market cap. This statement indicates a very basic lack of understanding of how the Bancor protocol works.

Moreover, the whole point of the the Bancor protocol is to enable an automatic, decentralized, transparent, trustless and straightforward management of the reserve(s), by the smart token itself. What you suggest here is counter to the entire vision of Bancor, and kind of reminds us of how central banks operate today.

To be fair, a Bancor proponent would say, “but you are committing provable reserves to your currency.” To which the answer is, “there are many other ways of proving your reserves, none of which tie you down to a dirt simple and flawed strategy for life.”

It’s not about “proving” the reserve exists, it’s about letting an autonomous and predictable smart-contract manage it, for the benefit of all token holders.

It is much better to manage the reserves manually than to commit to the Bancor strategy.

If you held the reserves yourself and issued buy and sell orders, like everyone else, you could not only follow the Bancor strategy to the letter if you liked, but you could use any other strategy that you preferred. You’d have the benefit of the immense neural network that you carry behind your eyes, and the freedom to switch strategies at any time.

We see here the same error of ignoring the fact that the Bancor protocol issues and destroys tokens according to demand (or lack thereof) for the smart token. The author(s) continue to suggest that this can be done by the token creator, holding the reserve, while ignoring the fact that the creator would require the ability to issue and destroy tokens at will.

Additionally, this kind of “financial strategic thinking” is exactly what the Bancor protocol aims to remove the need for. It is hard to imagine a member of the mother’s community currency that we operated, taking the role of the strategic mind behind the currency’s buy and sell orders. We know this because we tried it live with them for years. They are more likely to prefer an automatic mechanism that sets the price to balance their import/export ratio to/from other community currencies (which is exactly what the Bancor protocol does well). Our pilots show us that simple, predictable calculations operate better on average. Different strategies for managing reserves can prove to be successful or disastrous, while Bancor’s code simply constantly readjusts the price toward an equilibrium between buys and sells. The strategy of the Bancor protocol is to constantly seek a “balance of trade” equilibrium between different assets with no labor or strategic thinking required.

The Bancor strategy sets prices independent of the market.

The prices that Bancor offers for tokens have nothing to do with the actual market equilibrium. Bancor will always trail the market, and in doing so, will bleed its reserves. A simple thought experiment suffices to illustrate the problem.

There are several errors in this short sentence.

First, a smart token (not “Bancor”) cannot bleed reserves, simply because the price is set according to its current reserve balance. The issue raised here is a mathematical impossibility. Even if a smart token may “trail the market”, the price is constantly adjusted toward the equilibrium price. The “trailing” effect means that when the perceived value rises, the first ones to purchase it get a better price, and when the perceived value drops, the first ones to liquidate it get a better price. All this is possible since smart tokens have a common liquidity pool (“reserves”), “owned” by the collective of the token holders, rather than by traders and market makers that seek to maximize their profits from advance knowledge and who typically thrive in volatile markets. For the average user, the Bancor protocol, which stabilizes prices, seems like a much better choice compared to existing solutions.

Suppose that market panic sets around X. Unfounded news about your system overtake social media. Let’s suppose that people got convinced that your CEO has absconded to a remote island with no extradition treaty, that your CFO has been embezzling money, and your CTO was buying drugs from the darknet markets and shipping them to his work address to make a Scarface-like mound of white powder on his desk.

Worse, let’s suppose that you know these allegations to be false. They were spread by a troll army wielded by a company with no products, whose business plan is to block everyone’s coin stream.

What’s your best strategy if you were in control of your $10M in reserves and were manually setting prices?

We don’t know about you, but we’d hold the reserves tight and assuage the market. Maybe hold a press conference with the CEO, have the CFO show the books to an auditor, and present a sober and somber CTO describe how he was just making ginger bread houses with powdered confectionary for a fundraiser when he happened to sneeze. At the end of such a painful episode, we’d have battle scars, but also $10M in the bank.

The whole idea behind Bancor is that the reserve is not for you to hold. It is not owned by you. It is not yours to manipulate with a staged press conference pitching calming sound bites to naive consumers of fake news in order to generate the market effect you desire, nor to hold hostage while you fight righteously against the injustice of an unfair media. It is owned collectively by the token holders. It functions as their common liquidity pool, which is also used to set the price, keeping a constant ratio between the value of the liquidity pool and the smart token market cap. If your CTO is caught with cocaine, it is likely your token’s price will reflect this, as it probably should. Luckily, if you exonerate him or her, it is likely that your token’s price would then climb as users purchased it with the reserve token, betting on a brighter future. The author seems to miss the very basic functionality that as the price goes back up, the reserve goes up with it, making the “crescendo” at the end of this claim (having $10m in the bank despite a major confidence crisis) precisely the counter point.

Just as deterministic supply may be considered an advantage for a currency, deterministic reserve management (i.e. pricing mechanism) seems to offer a trustless, fair and practical solution, which benefits end-users with a more stable medium of exchange and a reserve that is always available.

If you used Bancor, your Bancor smart contract would have no knowledge of what is happening out there in the real world.

Except that it will know, thanks to the mix of buy/sell orders that are processed by it. Every buy and sell order is an (arguably superior) source of knowledge as to what is happening in the real world.

It wouldn’t know the market movements,

Also false, as arbitrageurs are financially incentivised to “let the smart contract know” exactly what the market movements are, by buying and selling the token in reaction.

it wouldn’t know where the coin ought to be,

Who does? We can only know where the coin is right now in every market. Where the coin “ought to be” sounds arbitrary at best.

and it would follow its blind strategy of offering bid/ask prices.

Predicting the future is blind, while Bancor uses no strategy. Rather, it calculates the price based on actual, real-time buy/sell activity. It sees the only thing it needs to see, which is actual demand for the smart token as represented by real buyers and sellers making real transactions in real-time.

That strategy involves making a market through thick and thin, without any information about reality.

Except for the concrete information about actual buy/sell orders, which perfectly reflect how the crowd interprets the information about reality.

In fact, that reality is determined purely by external markets,

This statement is demonstratively false in two different aspects. First, it is clearly not a “fact” that prices for the long-tail of currencies will be determined by external markets. Second, claiming that a price is “purely” determined by external markets — seems to suggest that arbitrage activity will have no effect on the these market, which is obviously absurd.

and the contract will, unstrategically, use its reserves to discover and match what the markets demand of it at that instant.

This is a very poor way of describing it. It is more accurate to say that the contract will use the actual buy/sell activity to discover the price, which makes much more sense.

In this case, Bancor would offer ever decreasing prices for X coins during a bank run, until it has no reserves left. You’d watch the market panic take hold and eat away your reserves. Recall that people are convinced that the true value of X is 0 in this scenario, and the Bancor formula is guaranteed to offer a price above that. So your entire reserve would be gone.

There seems to be quite a fundamental and repetitive misunderstanding, reflected in referring again to the reader/token creator as the owner of the reserve (“your entire reserve”). The reserve is not owned by any single party. It is the common property of the token holders.

In the example presented here, using the classic exchange model, prices would drop instantly (inflicting huge losses on the token holders), while with Bancor, since the smart token holders collectively own the reserve, and it must be held at a constant ratio to the smart token’s supply, some of those losses would be mitigated, as well as the potential hysteria. We do not consider this to be a disadvantage.

The Bancor strategy fails to capitalize on excess value

Now, a Bancor proponent would say “ok that was bad, but you’re not giving us the full story. After your press release, people would start buying your coins, and the contract would rebuild its reserves.”

Ok, let me illustrate what happens on the upside, and make the case that what they are saying is correct, but also incredibly inefficient. It’s like saying “hey, your nerves do grow back after spinal injury.” Yes, they do. Not so clear that you’ll walk again.

Let’s imagine that on the day of your big press conference, with the CEO, clean books, sober CTO and a new head of HR, your engineering team announces a new deterministic, asynchronous consensus protocol that takes a constant number of rounds [1], and a perpetual motion machine [2]. The crowds now love you. They go from dumping your shares at any price to fighting each other tooth and nail to buy your shares. In the time between ethereum blocks, a single X is worth infinity dollars on third-party exchanges. You could now literally sell just a single coin and retire forever.

But instead, you’re using the Bancor strategy. The smart contract doesn’t know that these changes are taking place. What it will do is offer to sell that first X for dirt cheap. It will fail to capitalize, on your behalf, on the difference between infinity and its sad, algorithmically determined low price.

It will not “fail” to capitalize, it may only take more time to capitalize, while benefiting the entire community by accumulating a reserve which softens not just price increases, but also price decreases.

It just doesn’t know. That extra money will get burned as miners’ fees, as people try to outbid each other to own this token at the huge discount offered by the oblivious Bancor platform.

The entire scenario detailed here is deeply flawed, ignoring a critical component of the Bancor ecosystem — arbitrage. In this scenario it is likely that a swarm of arbitrageurs will jump on the smart token’s next block, buying as many tokens as they can afford below the market price (eventually bringing the contract price inline with the market’s), depositing significant amounts into the reserve and then competing with each other to sell those tokens at a profit across the different exchanges. That scenario is not hard to imagine, and it will cause the price to quickly balance with external markets.

Essentially, we showed what happens when the true market price follows a step function between two extremes. The prices offered by the Bancor market making 40-liner will not follow this step function in tandem — it is necessarily inefficient. That inefficiency is wasteful and gameable.

We believe that while Bancor’s asynchronous price discovery method is new, it holds great promise to be more effective, not only in extreme scenarios like you describe, but certainly in more anticipated scenarios such as the community currencies we’ve been piloting. By effective we mean generating smoother price movement curves by incremental adjustments rather than volatile spikes, and with prices affected more by what people do than by what they think. We’d also recommend that you watch Bernard Lietaer’s talk on our website, where he explores the tradeoff between “efficiency” and “resilience”. We remind you that you advocate throughout this article for a system that has a proven very low resilience (albeit “high efficiency”), with massively negative outcomes for people.

The algorithmic dampening provided by Bancor isn’t desirable for already liquid assets whose value is unstable.

The previous two scenarios explored two extremes. But, to be fair, the following argument could be made in the steady-state case: “if your coins are locked up in this market maker, you lose the ability to insider-trade on the knowledge that most of the rumors about the CTO and CFO are false. However, this is simply a more general tradeoff between flexibility on one side and reliability on the other side — although you deny yourself the flexibility to make extra profits on private knowledge, your users gain the comfort of knowing that there exists this market maker which will dampen price movements, and that it will not go anywhere.”

This is true, the reserves do dampen price movements. If the price is going to be doing some ups and downs around a single mean value, Bancor can help facilitate trades by acting as a market maker.

But the situation is pretty bad when the price is leaving one level for another. If it’s going down, then Bancor will bleed its reserves to keep the price close to the higher point that the price used to be at.

Again, the same error is repeated, a reserve cannot “bleed” since it always maintains the constant ratio to the smart token’s market cap. In the case where the price is going down, it is advantageous for the holders to have it decline gradually due to actual buy/sell activity of the asset rather than due to the choices of market makers placing market orders — as the system works today.

And if it’s going up, Bancor will sell coins at a price lower than the equilibrium point of the market, and therefore slow down the up movement.

While the market will always balance on the equilibrium price, we see the slow movement that is based on actual capital flow — as a feature that benefits most value-adding users, not a bug. The goal of this shared liquidity is to create more stability for all.

The Bancor strategy will not do anything to find or maintain the true equilibrium value of an asset.

The preceding cases already illustrated the fundamental problem: Bancor is designed solely to maintain a reserve fraction. It has nothing to do with finding or maintaining the true value of an asset. It doesn’t know, yet it’ll blindly offer buy and sell bids. It’ll use its reserves to discover what prices it ought to set.

Again, a basic misunderstanding of the Bancor protocol is demonstrated here. The authors seem to miss that the reserve fraction does not require any “maintenance” and that the smart token does end up knowing its true demand, since it “knows” how much it is purchased or liquidated at any given price.

It should be clear, even to the casual reader, that if every purchased token raises the price, while every liquidation drops it, that the price will be constantly readjusted toward the point where the same amount of tokens are purchased and liquidated, on average, over time. How can anyone claim to understand these simple dynamics and maintain a claim that this model has nothing to do with finding the asset value equilibrium?

Bancor thus acts like a dynamically adjusted currency peg.

Currency pegs have been tried again and again: ask any Argentinian for details. Any time you have a central bank trying to use its reserves to buoy up a peg, you have the opportunity for gaming. You’ll recall that George Soros masterfully ran the reserves of the Bank of England down, simply by knowing their strategy. In this case, everything is happening on a public blockchain, using a fixed algorithm, with full visibility, while the true price is being set elsewhere through informed buy and sell orders.

These examples sound like fixed pegs, or manually set pegs, which are completely irrelevant in the discussion about trustless, automatic, dynamically priced, user-generated currencies we’re having.
The story about Soros is also irrelevant since Bancor reserves by definition cannot be “run”. Bancor would by design “protect” the reserves from such manipulation since their ratio to the market cap is constant, a defining feature of the Bancor protocol.

Bancor presents an arbitrage opportunity. It does not lead the market towards equilibrium, it trails the market, always and by definition.

The mismatch between the Bancor price and the true market price is the cost that Bancor pays to have its smart contract be informed of the true value of the asset.

Bancor does not “pay” for anything. It is all the token holders that “agree” to maintain a shared reserve that will soften the price increases, as well as the decreases, over time. We maintain that disincentivizing speculation while gaining continuous liquidity through a smart token that does not seek to profit from trades — offers more benefits to the smart token end-user than drawbacks.

It is not the case that Bancor is helping the market perform price discovery. Quite the opposite: it’s Bancor that is discovering the price, by virtue of offering buy and sell bids that are at odds with the value of the asset on the open market. It relies on arbitrageurs to bridge the gap and bring Bancor up to speed on what is happening. It pays a price out of its reserves for this function.

Indeed a smart token pays a price from its reserve when its price falls, thus mitigating it, but that price was paid from gains made to the reserve when the price was rising. That part seems to have been left out of the equation, creating the recurring false impression that the reserve can “bleed”.

As such, Bancor will always trail the true value in the open market, and act as a buffer or a dampener. Bancor uses its reserve to be informed of the delta between the price it offers and the price out in the open.

Embedded in here is an “old world” assumption that all tokens are traded and liquid in 3rd party exchanges. While we still maintain that the Bancor protocol serves as a positive price stabilizing force in such settings, the Bancor protocol truly shines with tokens that do not have the scale to overcome the double coincidence of wants problem that exchanges are dealing with. A vibrant community currency could be used frequently but purchased or liquidated only a few times an hour, and in small amounts. It would never become liquid in a classic exchange, as it would never generate fees that would be profitable above its listing overhead. However, it will always be liquid as a smart token. The long tail is typically an order of magnitude greater in total volume than the hits. This is where we see most of the immediate potential for the Bancor protocol, potentially measured in trillions as the long tail of user-generated tokens truly emerges.

Bancor does not “eliminate labor” in price discovery.

Despite Bancor’s claims that they eliminate labor in price discovery, their current contract does nothing of the sort. It simply shifts the market maker labor onto arbitrageurs. It is now the arbitrageurs’ job to notify the Bancor contract of the true price of an asset, and get paid a programmatic reward to do so.

Arbitrageurs do not attempt to determine the actual value of an asset the same way traders and market makers do. According to Investopedia: “An arbitrageur is a type of investor who attempts to profit from price inefficiencies in the market by making simultaneous trades that offset each other and capturing risk-free profits.”

It is clear from this description that there is quite a big difference between arbitrageurs and market makers. Developers are likely to notice that arbitrage would probably work best automatically, as a bot. Given all that, one can clearly see that the Bancor protocol can indeed offer an alternative to the labor of market making, since a counterparty is no longer required to complete a trade, and prices are determined automatically according to actual economic activity rather than by “laborers” whose job is to speculate on trends in order to increase personal gains.

There is no indication that the Bancor strategy is an optimal, or even good, use of reserves to discover the price.

The previous point was that Bancor uses its reserves to figure out where the market is, and sets a price accordingly. This isn’t inherently bad, but it’s neither what’s in the advertised materials, nor is there any indication that the formula they used is the best use of reserves.

Why not, for instance, a market making strategy that approaches the target price using a different formula? Or uses AI techniques? Or uses past history of price action? The depth of the order book? The possibilities, for the strategy that a central bank would follow to manage its reserves, are endless. Bancor picked just the simplest possible option. The space of options remains unenunciated and uncharacterized, and there is no indication why this approach is superior to others in the Bancor materials.

The simple goal of the formulas is to seek price equilibrium, and they do exactly that. How this price equilibrium is achieved is really not that important to the end-user. Price equilibrium is the point where the same amounts are converted to the currency and from it. It is the current balance point of the currency with the rest of the economy. If the community that uses the currency does better business, the demand will increase the currency price, allowing and encouraging the community to purchase more products and services offered by other communities, with their own currency (thus liquidating it). This is an example of why we see the equilibrium as the important element, and put less emphasis at the exact method by which it is discovered.

Bancor is a net negative in markets with substantial liquidity.

Bancor-style automatic trading should be suspended when the external markets are already liquid. Throwing a dampener at a liquid market, one whose motions are preordained and predictable by all, is not the best use of those reserves.

This claim is simply baseless. There is great potential motivation to keep a smart token activated in this case: increased price stability. A smart token that is liquid on exchanges, effectively uses the Bancor protocol to mitigate sharp price increases by collecting an additional reserve and issuing additional supply, as well as prevents sharp price decreases by releasing reserves and decreasing the supply. It dampens the price while still enabling it to go up or down, just less sharply so. We argue that stability has significant value to the token holder, though it is less good news for traders that profit from greater market volatility.

The sensible way to design Bancor is to place some limits on how much of its reserves it will use in any time period, to avoid the problems we identified. There are currently no provisions for this. Doing this well requires importing some facts about liquidity from the external world into Bancor, perhaps with the aid of oracles such as virtual notary, town crier, oraclize and augur. But at a minimum, some limits on how much of its reserves the contract will spend in any given time period seem called for.

It sounds like what is being offered is to impose limits on the reserve usage, which would limit the liquidity provided by the smart token for its holders. This direction is clearly at odds with our goal to enable continuous liquidity for the token holders, which we define as continually available for any size of trade at all time and with reasonable slippage relative to the currency market cap.

Bancor claims to provide liquidity, but does not.

Liquidity is the ability to buy or sell potentially large amounts without moving the price substantially.

The very definition used here for liquidity is the best proof that Bancor provides continuous liquidity. “Large amounts” and “moving the price substantially” are obviously relative terms. Specifically, they are relative to the asset’s market cap, the transaction size, and in the case of Bancor — also the CRR. The latter can be set by the user to fine tune the desired liquidity level relative to the market cap.

The Bancor contract does not guarantee this property, despite claiming that it does. Prices can move arbitrarily,

Price movements which are influenced by the actual buy and sell activity of a smart token are by no means “arbitrary”. We maintain that such activity provides better (and less “gameable”) input for the price discovery process.

and the price slippage is dependent on the amount bought or sold.

Which is exactly the case in exchanges today, only with unadjustable and unpredictable slippage. The Bancor protocol is an improvement on existing solutions in that regard.

This is a simple consequence of the fact that Bancor has no risk model and has no smarts. It’s simply a market trailing dampener.

This is again ignoring long tail use-cases in which there is no other “market” for a small-cap token to trail, as well as ignoring the potential positive balancing effect of the smart token, which is not simply “trailing” the market, but influencing it through the variable supply and the arbitrage activity it incentivises. “No smarts” is the opposite of what Bernard Lietaer called a “breakthrough,” and we think he’s pretty smart.

The preceding discussion examined the fundamental Bancor value proposition, in the abstract. Let’s now examine its instantiation in Ethereum.

Front Running

Bancor is open to front-running.

Bancor’s current implementation is open to a simple front-running attack. A miner, upon seeing that someone is submitting an order to buy from Bancor, would squeeze his own buy order ahead of the user’s. He would thus always get a rate from the Bancor market maker that is better than what the user gets. Every time.

Bancor has a “minReturn” concept, akin to a limit order, that ensures that if the order goes below a certain level of profitability, the user can cancel it.

But the miners know exactly what limits the users set. Ethereum transactions aren’t private. So a miner can squeeze in just the right order ahead of the user.

On the way down, front-running works the same way, with the miners squeezing sell orders ahead of the user, and thus pocketing the price difference.

And it’s possible for miners to automate this process with a simple software kit. Further, even non-miners can take advantage of this behavior, by paying higher fees to appear before the Bancor transaction in the block.

It would take quite some time for smart tokens to grow to the point where multiple buy/sell transactions take place in an average block, and we imagine that a large portion of the long tail of currencies can operate without ever reaching this threshold. For that scale, minReturn should serve as sufficient mitigation since it would cancel the transaction in an attempt to front run it (other solutions discussed below).

Bancor’s suggested fix to front-running is broken.

In a Twitter exchange, Bancor engineers mentioned that they are planning changes where they would charge the same fixed price to all transactions in the same block.

What they mentioned isn’t currently implementable on Ethereum, at least not in a straight-forward fashion. Transactions within a block execute completely independently. If there are two transactions T1 and T2 in a single block, T1’s execution occurs in isolation, without knowing about T2’s presence in the same block. So it’s not possible to charge T1 and T2 the same price, because T1 has no idea that T2 will execute in the future.

There are schemes we can imagine, where T1 and T2 are placed on the block first, and then a later “execute” transaction is placed on a subsequent block that looks backwards and gives the same price to T1 and T2. This gets around the limitation in the previous paragraph but it’s really ugly and kludgy, not to mention more expensive to execute and open to new attacks of its own.

In general, any scheme that a) provides full information to miners b) doesn’t include any nondeterminism and c) is vulnerable to ordering dependencies is gameable. Bancor and all their proposed modifications, including order floors and per-block prices, still satisfy all three.

This is only one of the solutions we have considered. And surely it could be improved. Luckily, we have deployed an upgradeable contract on which we can iterate towards perfection, while minimizing risks using a virtual reserve.

Also, even if some frontrunning does take place, we expected it to be drastically less exploitable compared to the current exchange-based financial ecosystem, where it is basically the market maker’s job to front-run the market based on proprietary information.

Nevertheless, we are well aware of this issue, and we are certain that if Bancor turns out to be indeed one of Ethereum’s killer apps (user-generated always-liquid currencies) a solution will be implemented to further mitigate front running.

We are able to take the needed time to build solutions addressing these challenges thanks to our experience, the trust and the resources we’ve received from the community. We don’t expect building the Bancor network to be a short journey or without bumps. Our job is to protect the nascent network in its first years until it can thrive on its own, and we take this guardianship we have been entrusted with very seriously.

Bad Math, Rounding and Lack of Testing

Bancor reimplemented math.

Bancor ended up reimplementing their own functions for arithmetic. That is, their own add, subtract, multiply, and exponentiation.

Counter to what is written here, we only implemented exponentiation, simply because a rational exponent isn’t natively implemented in Solidity and there isn’t any common battle tested implementation. We do use the native add, subtract & multiply and these are simply wrapped in an overflow protected abstraction which is common practice in smart contracts these days, FYI.

As an aside, this is sad to see for two reasons. First, finance applications should not have to worry about overflow errors. Ethereum should provide base types that make sure these kinds of reimplementations are never necessary in application code.

It’s not a ‘reimplementation’ if no implementation exists.

Second, no reimplementation of basic math routines should look the way Bancor’s code looks. It’s a mishmash of special numbers baked into the code. There is a certain style to writing code that is correct by construction. The code has to be crafted such that, not only is it correct, but it is easy to prove correct upon inspection. Bancor code is nothing like that, and baking magic numbers into the code is something for which we penalize first year undergraduates.

Here’s how Gnosis implemented ln. Here’s Vitalik’s similar suggestion.

As you can see, efficient math functions are usually not optimized for readability.

Bancor did not test their own math.

The sum total number of dedicated tests for these math functions is 6. Multiplication is tested solely by multiplying 2957 by 1740.

The coverage of the exponentiation function is abysmal. There are 0 directed tests that cover this critical function. There are other tests that take a quick path through exponentiation, but there are more than 30 different cases, and 30 different magic numbers embedded in the code. The existing, indirect, checks cover only a handful.

We’ve tested 1000s of test cases which we ran 1000s of times — it doesn’t make sense to create a test that takes 24 hours to run.
We also have hypothesis based test cases for even more tests.
And we just added (before the original post was published, mind you), more tests which we ran with more than a billion random number permutations that test the validity of the entire formula vs. a native python implementation.

Arithmetic errors can be fatal.

Special magic constants litter Bancor code. So much so that we found it difficult to test this code for correctness ourselves. There is an art to writing correct, clean code, and Bancor exhibits none of it. An error in any one of the constants would be catastrophic.

And even simple rounding errors can be problematic in this game. A rounding error can enable an attacker to buy-then-sell a token to Bancor, and make a fraction of a cent in the process. If they can earn such a small quantity above transaction fees, then they’d do exactly that all day long to drain funds.

It’s impossible to verify all possible test cases since each coin can have its own supply, reserve and CRR.

For that reason, we have a test specifically for the case described here, that verifies that rounding errors are always to the benefit of the entire community as opposed to the attacker, even without taking the transaction gas fee into account (described in a previous comment — which we ran on more than a billion different random permutations).

A final corner case to check for is what happens when the reserves are down to zero. The code needs to be able to recover from that scenario. The current code has special case handling for selling the entire supply. This seems strange for the continuous, path-independent Bancor formula.

This is a special case that allows the last sole holder of the token to be able to recover 100% of the remaining reserve without suffering from rounding errors.

Integration and Scale

Bancor does not support the notion of supply caps for Bancor-based tokens.

If the tokens that are based on Bancor are not actually securities, but serve as access tokens for a system, then they will typically correspond to some right to service. In many, though admittedly not all, scenarios, the system can only deliver a finite amount of service, so the designers will want to set a supply cap on their tokens. Yet Bancor’s smart contract will create tokens out of the thin air in response to demand.

It is true that most tokens are created out of thin air, however Bancor tokens are different as they are created out of a combination of thin air, plus a funded reserve token (and they are destroyed when this reserve is spent). What still seems to be overlooked, is that this very ability to create tokens on the fly is what enables smart tokens to function as hubs linking different (potentially supply capped) reserve tokens, thus linking these tokens to the Bancor network.

In this way, the Bancor protocol is backward compatible to support any ERC20 token, even if it has a capped supply.

There are additional solutions for capping supply (e.g. automatic “graduation” of a smart token to a fixed-cap with an automatically created token-changer), as well as simple solutions such as dynamic pricing which are based on the current supply. Per your example, if the system can only deliver 100 hours of service, one hour will initially cost 1% of the tokens. If 50 hours were purchased, an hour would cost 2% of the tokens, and so on.

This achieves the same effect.

Bancor does not scale.

Bancor generates continuous on-chain tx volume for arbitrage on tokens that nobody cares about by definition. If they did care, those tokens would have liquidity and not need Bancor. It requires continuous on-chain activity for what is currently primarily off-chain economic action.

This would be like saying that no one needs YouTube because the good stuff would surely make it to TV, while YouTube is for those videos “that nobody cares about by definition”.

It is simple to identify the “barrier to liquidity” that the classic exchange model poses, and it’s not that hard to imagine the endless new use cases which could emerge as soon as this barrier is removed.

Users Overpay

Bancor shortchanges its users.

Since the Bancor contract cannot issue fractional tokens, it simply takes your money and gives you a number of tokens rounded (see rounding above) to an integer.

The fraction that you do not receive goes to the reserve, for the benefit of all token holders, so it acts more like a tiny transaction fee benefiting everyone, and nothing like “shortchanging” as you attempt to describe it.

Since you don’t know when exactly your transaction will execute when you submit your bid, you have to pay both transaction fees to the miner to mine your transaction, and throw in an extra dollop of cash or coins to Bancor such that the contract can execute your trade without running under. If you guess wrong, you’ll end up, say, getting 0.99998 coins, which conveniently rounds down to 0.

That is not true. BNT tokens have 18 decimals — just like ETH, and thus the user can receive a fraction a lot smaller than the example given.
And in any case, rounding to the lowest fraction is true for every exchange and every currency in the world.

This will undoubtedly cause a lot of frustrated messages from users, who might feel that they submitted an honest bid, and got something short of their expectations.

That is a bit hard to imagine with 18 decimal point precision, to say the least.

Bancor whitepaper claims that you can predict what you will get back, but that’s patently false: in the presence of concurent users submitting transactions, you cannot predict at all. Any extra amount you overpay is usurped by the Bancor contract.

You can receive exactly as much as you asked for by passing the minimum return amount (note that you’ll still lose the transaction gas cost if the transaction didn’t meet the required amount).

Potential Reentrancy Issues

Bancor code is “difficult to prove correct.”

That’s code for “it’s a mess.”

Our auditor, Nick Johnson, praised us for the quality of our code and used it as an example for other projects as to how Solidity code should be written.

Well-written code looks like a work of art. It doesn’t matter if it’s C or Go or Ruby or Prolog; in fact, it looks especially like a work of art if it’s well-written C code. But it does matter if it’s Javascript, because well-written Javascript code is like the mythical Yeti: often discussed, with snippets of evidence for its existence, but no one has seen it in its full, corporeal form.

Bancor code was praised even as a direct response to this claim. There is very little more to say, except that perhaps an apology from Mr. Emin Gün Sirer for the proven misinformation he has spread about the Bancor protocol and the quality of its team’s work would be appreciated. Software development, specifically of end-user applications, is this team’s core competency.

The Bancor code has a distinct Javascript quality to it. This has been the hallmark of badly written smart contracts: they have messy code paths, don’t follow best practices, and happen to work by the skin of their teeth.

The code works on a good day with the wind on its back. But when it comes to corner cases, things get awfully complex. In the course I teach, when I point out such situations to students, they go into a diatribe that goes “well, you see, the problem can’t arise because for it to happen, A has to happen first, but A is guarded by B, and C ensures that B cannot happen.” This is a temporal logic proof, over a certain code path. It’s complex, fragile in the face of code evolution, and totally unacceptable in professional code development. We want flat, simple invariants, maintained by following best practices. Without regard for the correctness of the student’s code, we grade such cases a 2 out of 10. They ought to know better, and they’re 20 year olds with two years of programming experience.

Professionals working at the forefront of blockchain development at Ethereum Foundation think our code is quite sound, so there is a large discrepancy between their feedback and this post which would grade our dev team with a failing 2 out of 10. We would caution readers from condoning this quickness to judgement.

Our position on the code analysis above is that the code barely has code paths and heavily uses modifiers specifically to avoid them.

As an example, the largest contract — BancorChanger — has ~10 ‘if’ statements in ~400 lines (we do realize many of them are comments but the point is still valid).

The code does follow all best practices and industry style guidelines.

The only contract that has more complex code paths is the BancorFormula. It’s a necessity when writing optimized and precise fixed point math functions, and quite common in standard C math libraries. If you can suggest a better solution, we would be happy to consider it. We believe you will find this to be more challenging than it seems.

Bancor definitely has to know better, given The DAO experience.

It is quite absurd to even try to compare Bancor to TheDAO, given that the latter was used to store all funds, and had no pilot period with central control. It should be clear that Bancor functions as a trusted entity during the pilot period and executes any necessary upgrades. The Token Generation Event is over and the funds are stored in secure multi-sig wallets. We created the contracts in a way that minimizes the amount of ETH that is at risk. We also have the option to halt transfers/trades and upgrade the contracts. If that was the case with TheDAO, it probably would have ended quite differently.

So, in what follows, we will point out violations of best practices as problems. We did not have time to look into whether they are exploitable, because it’s tedious to do so and it’s immaterial. There ought to be no violations of best practices in a good contract.

As previously stated, our official auditors were Nick Johnson and Martin Swende and we fully trust their judgement on “best practices.” Their credibility in this domain is unquestionable. It should be interesting to understand why and how the author(S) have reached such radically different assessments regarding the quality of Bancor’s smart contracts. Nick Johnson actually took the initiative to praise it publicly in replies to those questioning it. However, I believe the responses to the raised concerns below can help in explaining this discrepancy.

Bancor code has a reentrancy problem in the sell() function.

There is what appears to be a reentrancy problem (recall that an exploitable reentrancy bug affected The DAO) in BancorChanger. Now, not every reentrancy bug is exploitable, and not every reentrancy bug gives rise to a The DAO like disaster. But nevertheless, there ought to be no state changes after a funds transfer, and there it is, right there on line 389 of the current (undeployed) code.

We cannot tell yet if this is exploitable, but it is disconcerting. There is no reason to perform a state change on something critical, such as virtualBalance, after the funds have been transferred.

Here’s an example to some of the external calls referenced here:

getSaleReturn does a call to _reserveToken.balanceOf(this), which is an external call to an enrolled reserve.
Same with getReserveBalance.
token.destroy() and token.totalSupply() are external calls, but it’s to the native token we’re controlling.
_reserveToken.transfer is also an external call to the enrolled reserve

So if a reserveToken is malicious or compromised, there are problems, and failing to update the virtual balance is the least of them.

The virtual balance update could be moved a few lines up — that would make it a bit easier to verify by eyes alone — but we don’t really see that this would make a material difference, given the fact that we need to call an external (enrolled reserve) contract anyway to be able to calculate the price. That said, we will even make this somewhat cosmetic change in the contract, as a nod to your point that code should be clearer at first glance.

Moreover, writing safe Solidity code doesn’t really have specific guidelines that work for every possible scenario, and being religious about not performing state changes after an external call can often lead to the same exploits it was meant to protect against. As a matter of fact, one could argue that it’s safer to perform state changes that “punish” the sender before external calls and state changes that benefit the sender after external calls.

Having said all that, the reserve token by definition has to be trusted. There is little sense in creating a smart token with an untrusted reserve. Not to mention BNT’s reserve token is actually the EtherToken contract that was written by us.

Bancor code has a different reentrancy problem in the change() function.

There is a similar reentrancy problem in change(). When going from one token to another (recall the “double coincidence of wants!”, perhaps it is referring to the double concidence of two different h4x0rs over the funds in Bancor), it performs, first, a buy() followed by a sell(). But buy() and sell() are both functions that call out of the Bancor contract. So it’s possible to get into a messy situation if the token transfers during the buy() or sell() operation call back into the Bancor contract.

Again, we cannot tell yet if it is exploitable, but it should be avoided. All transfers should happen after all the state changes.

The buy and sell calls are two separate functions that operate on two separate reserve tokens (and of course, the native token that we’re controlling). This is a simple ‘shortcut’ to perform two operations in a single transaction. The change call cannot possibly be more exploitable than the underlying operations since it doesn’t add any new logic to the mix that involves an external contract. Even in the unlikely scenario that one of the enrolled reserve tokens is malicious, and there was a security issue in either the buy or sell functions, the malicious contract could only exploit the operation in which it was involved — either buy or sell — not both.

Bancor code assumes that ERC20 tokens based on Bancor are cooperative.

The code assumes that the tokens layered on top of Bancor are cooperative. But ERC20 tokens can contain malicious code. It is difficult or impossible for Bancor engineers to vet the token code that is layered on top, and even if they do, it may be possible to change the ERC20 token contract after deployment.

We do have an assumption that if a token is used as a reserve, it is trusted — otherwise it would make no sense to use it as a reserve or at all for that matter. Nick Johnson wrote on this: “Malicious ERC20s are an explicit non-goal, as I understand it — since a malicious ERC20 could just issue an infinite number of tokens to its creator and let them draw down the reserve of the other tokens that way.”

Verdict

The Bancor code falls short of the narrative used to sell the code. Blindly making markets using a strategy that has no proof or reasoning for why it’s good is a flawed idea. Additional problems, such as front-running, potential reentrancy issues, poor code quality, lack of testing and the general unnecessity of inventing a new currency, give us pause.

The strategy has no proof because it was never tested in real life conditions. The good news is that it is finally about to be. As to the claim that there is no reasoning for why it’s good, we’ve indicated in this response the significant potential benefits of the Bancor protocol, though historically, industry experts and academics often fail to envision the potential benefits of emerging new ecosystems.

Keep in mind that there are lots of flawed ideas in the world. Not every flawed idea is catastrophic — we’ve done many things that definitely were not proven good ideas, and survived to be writing these words. Perhaps miners will be altruistic and avoid front-running,

Perhaps we should not so quickly assume that miners would mass-collude to steal money by running a code that exploits those who use the blockchain they operate, with potential negative impacts on the price of the currency they mine. We hope that you’ll survive this not proven good idea as well, as we look forward to an actual debate with you on any remaining open issues.

perhaps all the magic numbers are correct even though they are untested, perhaps there are no rounding errors that matter.

We have done the tests to assure this is the case, as noted earlier. This is not magic, it is diligence, and we highly recommend it.

But we know for sure that the Bancor approach is not the best use of one’s currency. Someone armed with additional information not on the blockchain can certainly make markets in a better informed fashion.

This is the same, recurring misunderstanding of the benefits offered by the common, transparent and automated market maker that is built into the smart tokens. We are not sure how one would know for sure that a never before implemented solution is not the best.

Since Bancor is possible to simulate off chain, committing to it on chain provides little to no additional value, except limit one’s future moves.

This is the same misunderstanding again, missing the point completely about why it would be good to “limit one’s future moves” when it comes to ownership of a reserve that is better shared by the community of token holder’s in a trustless and automatic way. The on chain reserve is the community’s shared treasury which helps to ensure continuous liquidity and relative price stability which benefit all.

Overall, it seems that the current Bancor approach is fundamentally inefficient and will bleed reserves.

Another repeated misunderstanding, as by definition, a reserve cannot bleed, but is held at a constant ratio to the market cap.

Assuming that there are no immediately exploitable issues in the code, and assuming that miners play nice and avoid front-running, we expect that we will see Bancor-based coins discover the limitations of the Bancor approach.

We expect them to discover, and break, the limitations of the classic, labor-based, heavily exploited bid/ask model, which suffers from a structural double-coincidence-of-wants problem and can in some cases be partially responsible for the rampant instability we see in markets around the world and throughout history.

To end on a positive note, the optimistic way to look at the Bancor episode is that it’s the first, flawed step in an interesting direction. It will surely be followed by more sophisticated approaches that have a better chance of living up to the hype.

We appreciate this “positive” ending that Bancor is a flawed step in an admittedly interesting direction. Why should it be “followed” by more sophisticated approaches? Couldn’t Bancor deploy and test these other approaches in the field? We seem to have the right experience, resources and infrastructure for this iteration if proven needed.

We welcome any discussion, always. We seek to engage with our strongest critics, because we believe it makes us better and stronger, and is appreciated by our community members who look to us to explain our approach in the face of challenges. We prefer to do this more respectfully for the benefit of the blockchain ecosystem, of which we are an undeniable part. Ultimately, we seek better solutions than the ones we have inherited, and we are open to collaborating with the best minds and hearts to find them.

People are beginning to look for ways to codify Janet Yellen and place her on the blockchain. True, she need have no fear of losing her job right now. But sooner or later, we will have actualy smart contracts that provide strong guarantees as they manage a currency.

Every long journey starts with one small step. We are thrilled and honored to be taking this first one, and humbled by the trust placed in us by the community through resources for the formidable journey ahead.