Posted on

Crypto Funds, Lending and Market Manipulation

Noelle Acheson is a veteran of company analysis and a member of CoinDesk’s product team. The opinions expressed in this article are the author’s own.

The following article originally appeared in Institutional Crypto by CoinDesk, a free newsletter for institutional investors interested in cryptoassets, with news and views on crypto infrastructure delivered every Tuesday. Sign up here.

It’s not easy being a crypto fund manager. As well as unruly markets and elusive valuations, there’s the increasing competition and pressure on fees. And performance has been lackluster: Vision Hill’s Q1 report showed that, on average, active funds have underperformed bitcoin so far this year.

The bear market of 2018 triggered the closure of many crypto funds, and a report released last week by PwC and Elwood Asset Management showed that there are far fewer active funds in existence than we had been led to believe.

The report also pointed out that, given a median management fee of 2% and a median fund size of $4 million, operational sustainability is tough: $80,000 recurring income is not enough to cover salaries and other overheads, especially given the likelihood of increasing compliance requirements.

The PwC/Elwood report mentions some steps that funds are taking to boost recurring income, such as market making and advisory roles.

It overlooks one potentially significant source of revenue, however: crypto lending. Funds could lend out the assets they hold, for a fee.

Given the growing demand for crypto lending services, this potential income stream could be enough to give a number of funds a greater chance of survival, as well as inject liquidity and diversity into the sector.

It could also, however, add hidden risk to the market overall.

Heading down

Before we look in more detail at this risk, let’s examine the trend toward lower fees.

According to the PwC/Elwood report, the median (mid-point) fee is 2%. This is in line with typical fees for “traditional” hedge funds. But there are signs that they are coming down. The report states that the average crypto fund fee is 1.72%, which means that many charge significantly less. This is also in line with the traditional sector, where fee pressure is already becoming the subject of headlines.

The pressure is even more acute in mutual and index funds, where fees are moving to zero or even lower. Last year, investment management giant Fidelity offered a mutual fund with no management charge. And earlier this month, the SEC greenlighted a fund from asset manager Salt Financial that promised negative fees.

Meanwhile, demand for crypto lending is growing at an astonishing pace, as the inflow of funds into lending startups and the demand from institutions shows. While there is no concrete data on the extent to which crypto funds lend out their assets, there are signs that this practice is spreading.

This has potential implications for the entire sector, both good and bad.

Heads up

On the positive side, increased lending of crypto assets could increase velocity and, by extension, price discovery as a greater number of transactions makes it easier for a market to express its views.

Furthermore, a growing demand for short selling, facilitated by asset lending, will to some extent enhance liquidity and help to develop a pool of natural buyers – all short sales have to be unwound eventually. This develops a “soft” floor for an asset price.

But “more liquid” does not necessarily mean “liquid,” and here is where the risk of market manipulation could seep in.

Let’s say I manage a crypto fund that has invested in altcoin A, and let’s say that I lend out part of my stake to counterparty A. In traditional finance, most securities loans can be recalled at any time – let’s assume that I can do the same here. I recall the loan of altcoin A, and counterparty A has to scramble to get it back to me. Whether counterparty A used the loan to sell short or lent it on to counterparty B, it will now have to buy the asset back in the market, probably pushing up the price by doing so.

Now, what if I knew that would happen, and used the recall as part of a strategy to boost my fund valuation? True, I probably couldn’t lock in the profit by selling altcoin A without pushing the market back down, but it could serve to fix a higher value on a certain date, which would boost my reported performance, which in turn could encourage more investment in my fund.

Plus, there’s the added benefit of knowing that the short sellers got squeezed, and the glory of my outperformance compared to those with a more negative outlook.

Obviously, if I got a reputation for doing this, no-one would borrow from me. And the drying up of that revenue stream could mean that I may end up having to liquidate my fund – just imagine what my dumping all of my altcoin holdings on the market (after recalling all loans) would do to other funds’ valuations.

Eyes open

One solution could be for investors to insist that the funds they back do not engage in this type of lending activity. But, given the difficulty of covering costs with declining management fees, that could make it less likely that compliant funds survive. And if the returns from lending boost fund performance, am I not obliged to seek the best possible return for my investors? Most investors in crypto hedge funds are themselves institutions, who are also judged by their performance. There is for now little incentive to insist on curbs on lending.

Regulation could come in and establish rules over transparency and oversight, as is happening in traditional finance. But regulators are still getting their heads around the crypto space, and are doing so at a cautious pace.

In the absence of clear rules, it is up to the sector to keep an eye on developments in both crypto fund administration and crypto asset lending. It is, after all, in its own interest to ensure a smooth and robust market.

But self-regulation has its own risks and is hard to execute in as opaque an activity as crypto asset lending. True, blockchain-based transactions are available for all to see – but most crypto asset lending is likely to take place off-chain, as an agreement between two parties.

However, letting the practice spread without some guidance could escalate systemic risk. As the traditional markets saw in 2008, the intertwined web of asset holdings through through opaque lending arrangements left institutions vulnerable and investors grasping at air.

Crypto markets have enough hurdles to overcome to reach mainstream acceptance. We shouldn’t let hidden risks that develop in front of our very noses to be one of them.

Lending image via Shutterstock

Posted on

I Underestimated Just How Many Subpoenas I Would Get

Steve Beauregard of the Bloq talks about his favorite work: answering subpoenas.

Subscribe to CoinDesk on YouTube:…

Twitter (Markets):

CoinDesk is the leading digital media, events and information services company for the crypto asset and blockchain technology community.

Posted on

Yes, You May Need a Blockchain

Balaji S. Srinivasan is the former CTO of Coinbase, a Board Partner at Andreessen Horowitz and a member of CoinDesk’s advisory board.

The following article originally appeared in Consensus Magazine, distributed exclusively to attendees of CoinDesk’s Consensus 2019 event.

There’s a certain kind of developer who states that blockchains are just terrible databases. As the narrative goes, why not just use PostgreSQL for your application? It’s mature, robust, and high performance. Compared to relational databases, the skeptic claims that blockchains are just slow, clunky and expensive databases that don’t scale.

While some critiques of this critique are already out there (1, 2), I’d propose a simple one sentence rebuttal: public blockchains are useful for storing shared state, particularly when that shared state represents valuable data that users want to export/import without error — like their money.

The data export/import problem

Take a look at the cloud diagrams for Amazon Web Services, Microsoft Azure, or Google Cloud. There are icons for load balancers, transcoders, queues, and lambda functions.

There are icons for VPCs and every type of database under the sun, including the new-ish managed blockchain services (which are distinct from public blockchains, though potentially useful in some circumstances).

What there isn’t an icon for is shared state between accounts. That is, these cloud diagrams all implicitly assume that a single entity and its employees (namely, the entity with access to the cloud root account) is the only one laying out the architecture diagram and reading from or writing to the application it underpins. More precisely, these diagrams typically assume the presence of a single economic actor, namely the entity paying the cloud bills.*

But if we visualize the cloud diagrams for not just one but one hundred corporate economic actors at a time, some immediate questions arise. Can these actors interoperate? Can their users pull their data out and bring it into other applications? And given that the users are themselves economic actors, if this data represents something of monetary value, can the users be confident that their data wasn’t modified during all this exporting and importing?

These are the types of questions that arise when we think about the data export and import from each entity’s application as a first-class requirement. And (with exceptions that we’ll get into), in general, the answer to these questions today is typically no.

No — different applications typically don’t have interoperable software, or allow their users to easily export/import their data in a standard form, or give users certainty that their data wasn’t intentionally tampered with or inadvertently corrupted during all the exporting and importing.

The reason why boils down to incentives. For most major internet services, there is simply no financial incentive to enable users to export their data, let alone to enable competitors to quickly import said data. While some call this the data portability problem, let’s call it the data export/import problem to focus attention on the specific mechanisms for export and import.

Current approaches to the data export/import problem

Even though the financial incentives aren’t yet present for a general solution to the data export/import problem, mechanisms have been created for many important special cases. These mechanisms include APIs, JSON/PDF/CSV exports, MBOX files, and (in a banking context) SFTP.

Let’s go through these in turn to understand the current state of affairs.

  • APIs. One of the most popular ways to export/import data is via Application Programming Interfaces, better known as APIs. Some businesses do let you get some of your data out, or give you the ability to write data to your account. But there’s a cost. First, their internal data format is typically proprietary and not an industry standard. Second, sometimes the APIs are not central to their core business and can be turned off. Third, sometimes the APIs are central to their core business and the price can be dramatically raised. In general, if you’re reading or writing to a hosted API, you’re at the mercy of the API provider. We call this platform risk, and being unceremoniously de-platformed has harmed many a startup.
  • JSON. Another related solution is to allow users or scripts to download JSON files, or read/write them to the aforementioned APIs. This is fine as far as it goes, but JSON is very free form and can describe virtually anything. For example, Facebook’s Graph API and LinkedIn’s REST API deal with similar things but return very different JSON results.
  • PDF. Another very partial solution is to allow users to export a PDF. This works for documents, as PDF is an open standard that can be read by other applications like Preview, Adobe Acrobat, Google Drive, Dropbox, and so on. But a PDF is meant to be an end product, to be read by a human. It’s not meant to be an input to any application besides a PDF viewer.
  • CSV. The humble comma separated value file gets closer to what we want for a general solution to the data import/export problem. Unlike the backend of a proprietary API, CSV is a standard format described by RFC 4180. Unlike JSON, which can represent almost anything, a CSV typically represents just a table. And unlike a PDF, a CSV can typically be edited locally by a user via a spreadsheet or used as machine-readable input to a local or cloud application. Because most kinds of data can be represented in a relational database, and because relational databases can usually be exported as a set of possibly gigantic CSVs, it’s also pretty general. However, CSVs are disadvantaged in a few ways. First, unlike a proprietary API, they aren’t hosted. That is, there’s no single canonical place to read or write a CSV representing (say) a record of transactions or a table of map metadata. Second, CSVs aren’t tamper resistant. If a user exports a record of transactions from service A, modifies it, and reuploads it to service B, the second service would be none the wiser. Third, CSVs don’t have built-in integrity checks to protect against inadvertent error. For example, the columns of a CSV don’t have explicit type information, which means that a column containing the months of the year from 1-12 could have its type auto-converted upon import into a simple integer, causing confusion.
  • MBOX. While less well known than CSV, the MBOX format for representing collections of email messages is the closest thing out there to a standardized data structure built for import and export between major platforms and independent applications alike. Indeed, there have been papers proposing the use of MBOX in contexts outside of email. While CSV represents tabular data, MBOX represents a type of log-structured data. It’s essentially a single huge plain text file of email messages in chronological order, but can also represent images/file attachments via MIME. Like CSV, MBOX files are an open standard and can be exported, edited locally, and reimported. And like CSV, MBOX has the disadvantages of no canonical host or intrinsic data integrity check.
  • SFTP. Before we move on, there’s one more data export/import mechanism that deserves mention: the secure file transfer protocol, or SFTP. While venerable, this is actually the way that individuals send ACH payments back and forth to each other. Essentially, financial institutions use SFTP servers to take in electronic transaction data in specially formatted files and transmit it to the Federal Reserve each day to sync ACH debits and credits with each other (see here, here, here, and here).

Each of these mechanisms is widely used. But they are insufficient for enabling the general case of tamper-resistant import and export of valuable data between arbitrary economic actors — whether they be corporate entities, individual users, or headless scripts. For that, we need public blockchains.

Public blockchains enable shared state by incentivizing interoperability. Public blockchains convert many types of data import/export problems into a general class of shared state problems. And they do so in part by incorporating many of the best features of the mechanisms described above.

  • Public blockchains provide canonical methods for read/write access like a hosted corporate API, but without the same platform risk. No single economic actor can shut down or deny service to clients of a decentralized public blockchain like bitcoin or ethereum.
  • They also enable individual users to export critical data to their local computer or to a new application like JSON/CSV/MBOX (either by sending out funds or exporting private keys) while providing cryptographic guarantees of data integrity.
  • They provide a means for arbitrary economic actors (whether corporations, individual users, or programs) to seamlessly interoperate. Every economic actor who reads from a public blockchain sees the same result, and any economic actor with sufficient funds can write to a public blockchain in the same way. No account setup is necessary and no actor can be blocked from read/write access.
  • And perhaps most importantly, public blockchains give financial incentives for interoperability and data integrity.

This last point deserves elaboration. A public blockchain like bitcoin or ethereum typically records the transfer of things of monetary value. This thing could be the intrinsic cryptocurrency of the chain, a token issued on top of the chain, or another kind of digital asset.

Because the data associated with a public blockchain represents something of monetary value, it finally delivers the financial incentive for interoperability. After all, any web or mobile app that wants to receive (say) BTC must honor the bitcoin blockchain’s conventions. Indeed, the application developers would have no choice due to the fact that bitcoin by design has a single, canonical longest proof-of-work chain with cryptographic validation of every block in that chain.

So, that’s the financial incentive for import.

As for the incentive for export, when it comes to money in particular, users demand the ability to export with complete fidelity, and very quickly. It’s not their old cat pics, which they might be ok with losing track of due to inconvenience or technical issues. It’s their money, their bitcoin, their cryptocurrency. Any application that holds it must make it available for export when they want to withdraw it, whether that means supporting send functionality, offering private key backups, or both. If not, the application is unlikely to ever receive deposits in the first place.

So, that’s the financial incentive for export. Thus, a public blockchain economically incentivizes every economic actor that interacts with it to use the same import/export format as every other actor, whether they be corporation, user, or program. Put another way, public blockchains are the next step after open source, as they provide open data. Anyone can code their own block explorer by reading from a public blockchain, and anyone can create their own wallet capable of writing to a public blockchain.

That’s a real breakthrough. We’ve now got a reliable way to incentivize the use of shared state, to simultaneously allow millions of individuals and companies access to read from (and thousands to write to) the same data store while enforcing a common standard and maintaining high confidence in the integrity of the data.

This is very different from the status quo. You typically don’t share the root password to your database on the internet, because a database that allows anyone to read/write to it usually gets corrupted. Public blockchains solve this problem with cryptography rather than permissions, greatly increasing the number of simultaneous users.

It’s true that today public blockchains are typically focused on monetary and financial applications, where the underlying dataset represents an append-only transaction history with immutable records. That does limit their generality, in terms of addressing all the different versions of the data import/export problem. But there’s ongoing development on public blockchain versions of things like OpenStreetMaps, Wikipedia, and Twitter as well as systems like Filecoin/IPFS. These wouldn’t just represent records of financial transactions where immutability was a requirement, but could represent other types of data (like map or encyclopedia entries) that would be routinely updated.

Done right, these newer types of public blockchain-based systems may allow any economic actor with sufficient funds and/or cryptographic credentials to not just read and write but also edit their own records while preserving data integrity. Given this capability, there’s no reason one can’t put a SQL layer on top of a public blockchain to work with the shared state it affords, just like an old-fashioned relational database. This results in a new type of database with no privileged owner, where all seven billion humans on the planet (and their scripts!) are authorized users, and which can be written to by any entity with sufficient funds.

That day isn’t here yet. It remains to see how far we can push the use cases for public chains. And scaling challenges abound. But hopefully, it’s clear that while public blockchains are indeed a new kind of database, they offer something quite different than what a traditional database offers.

* The one exception is the so-called “Requester Pays” feature that Amazon and other cloud services offer. This is a cool feature that lets someone pay to write to your S3 bucket. But it’s permissioned – it still requires every would-be writer to open an AWS account, and the bucket owner has to be willing to let them all write to their bucket, so there’s still a single distinguished owner.

Database image via Shutterstock

Posted on

Florincoin – the 2014 Altcoin You Don’t Remember – Is Attracting Real Users

One of the most recognizable names in the crypto space (and perhaps even outside of it) is using one of the least recognizable blockchains. subsidiaries Medici Ventures and tZERO have been utilizing the FLO blockchain for some time in work aimed at re-organizing property rights. At one time, a video of the tZERO homepage even showed the little-known blockchain at work.

Still, if you haven’t heard of FLO before, you won’t be alone. Maybe Florincoin, the blockchain’s moniker when it first launched in 2013, shortly before the 2014 altcoin boom – will ring a bell, at least those who were in New York at the time.

Joey Fiscella was a staple in the growing New York City crypto community during that area. A young, extroverted programmer, he had the ability to schmooze with the best of the business types. While the rest of the scene was focused on bitcoin, to a certain extent litecoin and for the lolz dogecoin, Fiscella was instead always talking Florincoin – a coin that’s visage bears a golden fleur-de-lis.

He was a regular at the New York Bitcoin Center and was always handing out thin strips of paper with Florincoin private keys (I used to have one, but as is the nature of small scraps of paper, it has been lost).

The idea was simple: Florincoin was bitcoin but with additional room for transaction comments, 140 characters at that time. And those characters would allow a decentralized social media (what else had a 140-character limit back then? Twitter), one that couldn’t be censored or stopped.

It’s a dream that’s still being toyed with today – from Steemit to Peepeth to Minds – but since then Florincoin, now FLO, has moved on.

Today, most of the developers and businesses involved in FLO are interested in it as an indexing tool, something that could provide the backbone of a blockchain-based Google.

Not only has Medici Land Governance begun adding property records on the FLO blockchain (and partnered with the state of Wyoming, the city of Tulum in Mexico and a government official in Zambia), but T-zero is adding digital locate receipts, which locate the ownership of a stock, into FLO to mitigate naked short selling.

On top of that, FLO is being utilized by the Open Index Protocol (OIP), a database for decentralized publishing of all kinds, and an app on top of OIP called Alexandria, which allows users to search and browse info in that database.

The list of users goes on too.

The California Institute of Technology, also called Caltech, uses FLO to store more than 17,000 records of information gathered with microscopes, and just recently announced the creation of another repository of microscope data.

So how, a crypto enthusiast might ask, did FLO become a blockchain with actual users (and seemingly without gloating in the hopes of sparking a price pump)?

According to Chris Chrysostom, a senior software developer at Medici Ventures, “As a developer I’m always open to looking at other solutions; people mention bitcoin a lot because right now it’s a good starting point for communicating concepts.”

But, he continued:

“One thing that FLO provides that bitcoin doesn’t is, right now, it has the ability to accept 1,040 bytes of metadata. FLO is able and willing to take on the blockchain bloat that many people are critical of in bitcoin.”

The bytes and the bloat

To understand how one of the most-anticipated and regulated token projects in the space came to use a blockchain that most people don’t even know about, you have to start with its first real business case.

Utilized by husband and wife team, Devon and Amy Reed, Florincoin became the underlying technology of the Decentralized Library of Alexandria (DLOA).

A blatant nod to the ancient world library that was burned down (while it’s become a modern-day symbol for the loss of cultural knowledge, the crypto project used it as a way to illustrate the problems inherent to centralization), the project was initially touted as a decentralized library. According to Amy, the co-founder of the project, in an earlier interview, all types of content, including books, blogs, video, audio and art could be added to the blockchain and secured from censorship.

DLOA was the forefather of today’s decentralized content platforms, hoping to untangle the messy distribution models that currently exist for content creators and viewers online.

The project chugged along for a couple of years quietly, until Tim Berners-Lee, the creator of the World Wide Web and the founder of the W3C, a standards organization for the web, was given a demo of the app.

According to Amy, Berners-Lee loved it, but said: “change the name.”

So the application – a Google-like search for the data, became just Alexandria and the protocol, which allows content creators to decide how their content is categorized before adding it to the FLO blockchain, became known as the Open Index Protocol (OIP).

And as that change happened, the number of bytes that could be stored in a transaction was increased as well – from 140 to 528 and then to 1,040, the limit today. But what’s perhaps the most fascinating about OIP is that in a mess of new competition, the project has stuck with FLO.

From Storj to Filecoin or even more broadly ethereum or EOS, there’s a slew of blockchain projects looking to tackle a similar use case – decentralized file storage – and these new players tout advanced architecture that makes their platforms faster, stronger, overall better.

But Devon remains unphased by the shiny new toys.

“When we started the project, our goal was to build a shared data layer that is censorship-proof, persistent and as interoperable as possible,” he told CoinDesk. “This required certain technical choices, which FLO fit perfectly – and even though other things have been launched since which do a variety of things, they don’t meet those needs better than FLO does.”

For that index that OIP is, Devon contends, the project needs full global state replication (to make censorship attempts transparent), proof-of-work consensus (to make censorship attempts expensive and defensible) and the ability to directly benefit from bitcoin’s developer community (a fork of bitcoin).

According to Devon Reed, sure, OIP could instead store its index on ethereum, and with that gain a different developer community and plenty of hype.

But, he said, the project would lose in other ways. For instance, after sharding is implemented, the project wouldn’t any longer get full global state replication; and after Casper – ethereum’s switch to a proof-of-stake consensus algorithm – the project wouldn’t have the security of proof-of-work.

On top of that, the publishing fees would no longer be decided by the OIP working group, and would instead, entirely be a function of the gas costs – priced by the ethereum core developers – of certain operations.

For many intents and purposes, FLO has become a kind of single purpose blockchain specifically for OIP. And that wasn’t a bad thing for FLO. While other institutions are starting to use FLO now, for many years Devon and Amy were the only ones really focused on FLO and they brought in a significant number of the developers that work on the blockchain to this day.

The original angel

Take Sky Young, a senior full stack developer at, who started working on the FLO protocol because of her role with Alexandria in August 2015.

Or Jeremiah Buddenhage, also known as bitspill, who began developing on the FLO blockchain after he completed and claimed a bounty posted by the Alexandria team to update the protocol. After that, Buddenhage told CoinDesk, Alexandria offered him contract work until hiring him as a full stack developer in the summer of 2017.

Both developers get paid to work on OIP, which many times involves the development of FLO, keeping the blockchain up-to-date, probably more so than it would be were there not a company so tied into its success.

Before OIP and Alexandria, there was only FLO’s (then Florincoin’s), creator, a pseudonymous developer going by the moniker SkyAngel. It’s pretty similar to bitcoin’s Satoshi Nakamoto, although SkyAngel remains around here and there, said Fiscella.

SkyAngel did not return requests for comment.

In June 2013, Fiscella was trolling crypto forums looking for altcoins to mine and stumbled on FLO – hours after the software was released, he began mining the cryptocurrency and after noticing a couple of bugs (nothing consensus-related) in the code, he contacted SkyAngel within a week of its release. He’s been volunteering his time towards development ever since.

And while Fiscella got his fair share of shit for messing around with FLO – this was back in the day when people thought all altcoins were useless or worse, scams – there’s a sense of pride now.

“FLO is one of the oldest altcoins that is still actively traded and developed,” he told CoinDesk.

And it’s done so, he continued, without a pre-mine for developers, without raising huge amounts of money in an initial coin offering (ICO), without even a million dollars from a venture capitalist. Although, the FLO developers have raised $50,000 from the community over the past six years and the OIP and Alexandria team have raised a few $100,000 here and there, which they used to continue FLO development.

As such, many of the developers working on FLO right now are also pretty happy with the way it’s all turned out.

For instance, Young describes FLO as “hidden” and “undervalued.” And although Buddenhage was initially only attracted to FLO as a way to make money from small programming gigs, his “appreciation and understanding” has grown significantly over the years.

He told CoinDesk, “The big idea that made me want to keep working on this project is the idea of building a public space – allowing users to determine the worth of their own work and for the consumers to determine if it’s appropriate (rather than being held to the mercy of rates decided by a private company or a vague definition of ‘advertiser friendly’).”

In describing my story, meeting Fiscella years later at a crypto meetup and thinking, ‘Holy shit, Florincoin still exists,’ Buddenhage, who’s been in the space since 2013, laughed, saying:

“It’s great to see people react when they re-discover that FLO/Alexandria have not joined the ranks of shitcoin yet nor is it merely idling on but has actually grown in the shadows.”

Enter tZERO

It was Chris Chrysostom, a developer that was looking to build a simple application called a bill of sale on a blockchain, that found FLO and eventually brought it into the Medici ranks.

While he began the project hoping to utilize bitcoin’s OP_RETURN feature, Chrysostom quickly became frustrated with that because cumbersome to use and doesn’t hold enough data to create anything substantial. So he started looking around, reading through some content about Factom and the Storj white papers, both of which mention FLO (again Florincoin at that time).

That led Chrysostom to Alexandria, where he worked alongside Devon and Amy, building out the project’s payment capabilities.

Then in July 2017, he was picked up by Medici Ventures.

Now a senior software developer at the venture capital subsidiary of, Chrysostom brought to the job his interest in FLO. Chrysostom was assigned to a project within Medici Ventures focused on property rights – the idea being a global property rights registry – and FLO and the work being done by the Open Index Protocol seemed like a natural fit there, he told CoinDesk.

“We use it specifically for projects, proofs-of-concept and research for this property rights project,” he said.

While Patrick Byrne, the founder and CEO of Overstock, announced a partnership in late 2017 with Peruvian economist Hernando de Soto with a similar intent, Chrysostom said his work using FLO at Medici Ventures was different, yet could easily support the De Soto project if necessary.

According to Chrysostom, he was looking for a proof-of-work blockchain with similarities to bitcoin, so many similarities that the development work on bitcoin’s core team could then be applied to the other blockchain as well. For instance, security measures and scaling technologies like Segregated Witness.

“FLO was really appealing – bitcoin wants its use case to be focused on value transfer (and that’s fine); FLO has taken it upon itself to have a lot of similarities to bitcoin but with the added feature of application data,” Chrysostom said. “Which is more suited for the property rights use case.”

And sure enough, Chrysostom has similar things to say about the project’s ethos and morals.

“It’s really appealing that FLO hasn’t gone down the path of turning itself into an ICO; it didn’t try to segregate coins in a certain way, like the staking mechanisms; it’s quite admirable that it has remained an open-source project,” he said, adding:

“Four to five years have gone by, and it’s still about what its founding was all about – an open blockchain with a little extra use case. I just find it admirable that it’s stuck to that.”

And as for OIP and Alexandria, those teams get Chrysostom’s praise too since, according to him, they focused on building out the software instead of hyping the coin.

Chrysostom said:

“FLO has been quite the stealth coin in my opinion.”

While Chrysostom would, of course, love to see the developers and projects building on FLO get rewarded for their work, he understands that with investment comes responsibilities that might divert the focus away from the open index goal.

For Medici Ventures part, it does not provide investment to FLO developers, Chrysostom explained, although he continued, “If the day comes that someone wants to make a pitch to Medici Ventures … I think they’d listen. They listen to all kinds of things.”

Keeping it afloat

Still, that’s not to say everything has run smoothly in the FLO community.

For instance, toward the end of 2015, customers of Cryptsy, the only digital currency exchange that listed FLO, began having withdrawal issues, and shortly after the exchange claimed it was insolvent after a July 2014 hack.

While a class action was mounted at Cryptsy in the aftermath, the parties that brought the class action against the exchange didn’t list FLO as one of the coins you could redeem. According to Fiscella, there are 11.5 million FLO coins in one Cryptsy wallet that haven’t moved since February 2014, so he suspects not that the exchange’s founders ran away with the coins (because then they probably would have sold them off at some point) but that these coins could not be recovered by any party, the exchange or even law enforcement.

“It wasn’t worth anything at the time,” Fiscella said. “But FLO was once around 40 cents.”

At that price, the coins lost in Cryptsy would have been worth more than $4 million.

Since then Bittrex and Poloniex have also listed FLO (actually on the same day in March 2015), although Poloniex removed it shortly after the exchange was acquired by Circle. Poloniex didn’t give a reason for the delisting of FLO, though the coin was taken off the site with a handful of other altcoins.

While some thought the reason was low volume, Fiscella argues that other coins that were not delisted had lower volume than FLO, so really he speculates the delisting was about FLO’s low hashrate, which meant that FLO could be relatively easily 51% attacked.

This was right around the same time that Crypto 51, a website calculating the cost of 51% attacking (and then double spending) cryptocurrencies, appeared. Once that website was up, a number of cryptocurrencies, including bitcoin gold and vertcoin, began dealing with attacks.

And FLO, which was on the Crypto51 list with an attack price of only $300, was exploited on Bittrex in September 2018 and 25 bitcoins were stolen. The attack works like this: an anonymous account deposited hundreds of thousands of FLO coins into Bittrex, traded that FLO for the 25 bitcoins, withdrew the 25 bitcoins and then rewrote about 480 FLO blocks. In this way, the FLO deposit was reversed and the hacker was able to reclaim the hundreds of thousands of FLO they had initially deposited and was also out with the bitcoin as well. The wallet at the exchange then didn’t have the FLO to deposit into the accounts that had bought the altcoin.

When Bittrex’s system detected this, it shut down FLO trading for about a month, until the developers fixed the issue.

“And by fixed it, I mean we paid 700,000 FLO to Bittrex,” Fiscella said, adding:

“And by we, I mean me.”

Bittrex did not respond to requests for inquiry.

Joey used the FLO he had been mining since the beginning to pay back the exchange and other FLO developers set up a “Big Mac Fund” for Joey, where community members have donated about half of the 700,000 to Joey for his ongoing work on the protocol.

Before the attack happened, Fiscella had been discussing the issue with Alexandria’s Devon Reed, saying they needed to increase the hash rate before something like this happened. But it was too little, too late.

After the attack, the developers working on the protocol decided that FLO needed to add some additional security measures to the scrypt-based mining algorithm (an alternative to bitcoin’s SHA-256 algorithm) since scrypt-based mining made it easier for an attack to take place.

The developers decided to add an extra rule to the consensus algorithm, a so-called max reorg depth limit feature. This feature requires large reorganizations of the blockchain be rejected, and it’s a similar feature to that used by bitcoin cash and ravencoin.

If that sounds like something that could kill a cryptocurrency, make people so skeptical of its security and value that they sell off their bags and leave it to die, it’s definitely happened before.

But FLO has endured and actually, it’s developers learned from its mistakes and evolved.

“The people who have joined have not asked to be paid, they’re just activists or investors,” Fiscella told CoinDesk, adding: “Everyone joined organically and they’re using their skills and network to grow the community. I think that’s really important.”

Today, there are about 10 active mining pools and another 10 that sometimes mine FLO, which increases the robustness of the coin. Also in early 2018, FLO’s code was updated to Segregated Witness, a protocol change that adjusts the way data is stored, making blockchains more scalable.

Echoing Fiscella’s comments about FLO being successful because of its determined developer community, Buddenhage concluded:

“They all appear to know what they’re doing and why they’re here putting in the effort whenever/wherever life/work allows the opportunity being that it’s a side project and volunteerism keeping it going, perhaps slowly at times but always moving forward with dedication and purpose.”

FLO coins featured image via; images in the article via Joey Fiscella