Disclaimer: I am not a lawyer, and I am not your lawyer.

I have been in an uncountable number of conversations over the past few years discussing the question of what defines a “security” in the context of cryptocurrencies, cryptonetworks, and token offerings.

Here is my current understanding, including a number of key questions I am still working on. I invite any and all corrections to this visual framework. And I should note that this is a high-level framework: the nuanced details are the subject of many enforcements, settlements, and litigations and will be worked out over a long-period of time to come.

First: the what constitutes a “security” has been defined by the courts more specifically as an “investment contract”, which is a transaction with the following properties:

1. An investment of money
2. With the expectation of profits
3. In a so-called “common enterprise” (roughly meaning: investors and the company rise and fall together)
4. From the efforts of a promoter or third party (some dispute over whether this means “solely” from a promoter, but clear that it entails “significant managerial efforts” of a single promoter)

This four-part test was established as part of SEC vs. Howey, a 1946 supreme court case involving the sale of tracts in an orange grove, with an associated lease-back arrangement where buyers of the land leased the land back to the Howey corporation in exchange for profits generated from cultivation of orange crops. This so-called “Howey Test” is now the basis for determining whether such a transaction constitutes an “investment contract” and would therefore fall under securities laws (with all associated registration and disclosure requirements).

The way the test works is that, if the contract satisfies all 4 “prongs”, it “passes” the Howey Test and is therefore a securities transaction. If the contract does not satisfy any one of the prongs, it fails the Howey Test and is therefore is not a securities transaction.

The 4 prongs of the Howey Test

Ok, with all of that as background, here is how I see the Howey Test — 4 prongs that all need to be satisfied:

So, if you were to start to think about how to “knock out” prongs of the test, thereby removing a transaction from securities status, you’d start one-by-one.

1) Remove the “investment of money” and what you have looks more like a Gift (think: receiving airline miles, or ride credits on Uber, or “airdrops” of tokens in a crypto network)

2) Remove the “expectation of profit” and what you have looks more like a product (think: pre-buying a backpack or movie on Kickstarter, purchasing laundry or arcade tokens, or buying Stacks Tokens to insert records in the Blockstack blockchain):

3) Remove the “common enterprise” and what you get looks more like a collectible (think unique items like stamps, baseball cards, or CryptoKitties):

4) Finally, remove the “efforts of a promoter or third party” and what you get looks more like a commodity (think gold, wheat, or Bitcoin or Ethereum):

All together, it looks like this:

Is a “security” an asset or a transaction?

A key question throughout all of this is whether the “security” is the digital asset itself, or instead the transaction involving the digital asset.

In a key speech by the head of SEC’s Corporate Finance Division, Bill Hinman, earlier this year, he addressed this question head on:

To start, we should frame the question differently and focus not on the digital asset itself, but on the circumstances surrounding the digital asset and the manner in which it is sold. To that end, a better line of inquiry is: “Can a digital asset that was originally offered in a securities offering ever be later sold in a manner that does not constitute an offering of a security?” In cases where the digital asset represents a set of rights that gives the holder a financial interest in an enterprise, the answer is likely “no.” In these cases, calling the transaction an initial coin offering, or “ICO,” or a sale of a “token,” will not take it out of the purview of the U.S. securities laws.

But what about cases where there is no longer any central enterprise being invested in or where the digital asset is sold only to be used to purchase a good or service available through the network on which it was created? I believe in these cases the answer is a qualified “yes.”

The Hinman speech clarified two things: 1) that by knocking out the “efforts of others” prong of the Howey Test (#4 above) a crypto asset transaction can be viewed through the lens of commodities vs securities and 2) that an early transaction of that asset (in this case the pre-sale of ETH) can be analyzed under Howey distinctly from a later sale, given different facts and circumstances at the time.

This last part is really important, and I still have a hard time pinning down (really smart, expensive) lawyers on the subject. There is an idea that a “security” is a thing rather than a transaction, which does seem at odds with both Howey and the Hinman speech. In the case of Howey, the oranges produced under the contract are not the same as the contract itself (similar to contracts for future tokens), and in the case of the Hinman speech, it’s the transaction rather than the underlying token (BTC or ETH).

Finally taking all of this together, it’s important to remember that 1) there are many kinds of cryptoassets, and 2) they are offered/sold/traded/transferred under different circumstances over time. I think about it like this:

I hope that is helpful. This is complicated stuff, and new territory.

Our good friend Chris Burniske was on Squawk Box this morning. I got up and watched it. You can see the video here.

Of course there is interest in the crypto market right now, as it is falling hard. I suspect there are many out there who are enjoying the drop, waiting for the bubble to finish popping and for this whole idea to go away.

One takeaway from watching the segment is how much of a learning curve there still is around this whole space. If you look at the questions Chris fielded this morning, you’ll see a looming gap in understanding of the fundamentals. The questions range from “why do we even need this” to “what is the rational basis for these prices”

It’s a complicated topic, with complicated mechanics, and to make matters worse, the narrative itself has shifted a bunch over time (digital cash, digital gold, decentralized computing, the new internet, etc).

Here is one way to think about it, that feels native to CNBC and the financial markets industry:

Crypto is a market-based system for providing computing services. The “miners” and other participants are just like the participants in other commodities markets. It really is a shift from providing computing services via a corporate/securities/centralized model to an ecosystem/commodities/decentralized model.

If you just hold that idea for a moment, then where Chris was trying to take the conversation (but didn’t exactly manage to — talk TV is tough!) is around the rational pricing of commodities. A simple way to start is by looking at the marginal cost of production, which is one way of looking at commodities pricing. While this does not make sense in a highly speculative bull market, it makes a lot of sense in a flat or bear market, as we seek a basis for understanding where the bottom might be.

Another challenge here is that the utility of cryptoassets like bitcoin ethereum is still being understood, so we do not yet have solid anchors for pricing. In the case of oil, for example, we have industries upon industries using it, establishing consumer value which lets price flow back to the original production. This is still nascent in the crypto space, but is getting clearer every day.

Thank you Chris for working to advance the dialogue.

One of my favorite things to do is get my hands into something and figure out how it works, whether that’s an app, or a gadget, or a house.

For example, over the past few months I have been renovating our basement, turning an unfinished, dank storage area into a playroom for the kids. Here is my friend Ned, and my son, as we were pouring the new concrete floor over the summer:

I get completely enraptured by a project when my hands are into it. There are so many details to figure out, and enjoying the final result, when you know exactly how much work went into it, is so satisfying.

Perhaps most importantly, getting hands on with anything is (for me at least) the best way to learn. When I learned programming, it was in the context of building apps and websites with friends — I learned as I went, and got deeper and deeper and deeper. Same goes for every single thing I’ve learned over the years (deeper in tech, legal, investing, crypto, etc). The more hands-on I am, the more fun I have, and the more I learn.

I have been thinking about this in the context of investing. Looking back over the years, at the times when I have felt the strongest sense of conviction about an opportunity, it’s the times when I was the most hands-on that I felt it the strongest.

At USV, we try to be users of every new platform that we invest in (in some cases this is easier than others). It is easy to say that, but also easy to forget it sometimes, especially in areas that are really new. But there is just no substitute for approaching things that way, for me at least.

With real-time, interconnected, self-executing systems, sometimes when things wrong, they go really wrong. I wrote about this general idea previously here.

Yesterday, while I was writing my post on Trusted Brands, I was doing a little searching through my blog archives, so as to link back to all the posts categorized under “Trust”. In the process of doing that, I went back and actually re-categorized some older posts that fell under that category, but weren’t appropriately marked. In the process of doing that, I came across a whole bunch of posts from 2013 that I had imported from my old Tumblr blog, but were still just saved as drafts rather than published posts.

So, I did a little test with one of them — hit Publish and checked that it looked right. Then, after that, I did a bulk-edit with about 15 posts, selecting all of them and changing the status from “draft” to “published”.

This did not have the intended effect.

Rather than those posts showing up in the archives under 2013, they were published as of yesterday. So now I have 15 posts from 2013 showing up at the top of the blog as if I wrote them yesterday.

That would not have been a real problem on its own — the real problem stemmed that because of our automated “content system” (that I built, mind you) within the USV team, those posts didn’t just show up on my blog, they showed up on the USV Team Posts widget (displayed here, on Fred’s blog and on Albert’s blog), they showed (via the widget) in Fred’s RSS feed, which feeds his daily newsletter, and blast notifications were sent out via the USV network slack. Further, some elements of the system (namely, the consolidated USV team RSS feed, which is powered by Zapier) is not easily changeable.

Because of the way this happens to be set up, all of those triggers happen automatically and in real-time. As Jamie Wilkinson remarked to me this morning, it is unclear whether this is a feature of a bug.

Of course, as all of this happened, I was on a plane to SF with spotty internet, and was left trying to undo the mess, restore things to a previous point, monkey patch where needed, etc.

Point is: real-time automation is really nice, when it works as intended. Every day for the past few years, posts have been flowing through this same system, and it’s been great. No fuss, no muss, everything flowing where it should.

But as this (admittedly very minor) incident shows, real-time, automatic, interconnected systems carry a certain type of failure risk. In this particular case, there are a few common sense safeguards we could build in to protect against something like this (namely: a delay in the consolidated RSS feed in picking up posts, and/or an easy way to edit it post-hoc) — maybe we will get to those.

But I also think about this in the world of crypto/blockchain and smart contracts, where a key feature of the code is that it is automatic and “unstoppable”. We have already seen some high-profile cases where unstoppable code-as-law can lead to some tough situations (DAO hack, ETH/ETC hard fork, etc), and will surely see more.

There is a lot of power and value in automated, unstoppable, autonomous code. But it does absolutely bring with it a new kind of risk, and will require both a new programming approach (less iterative, more careful) and also new tools for governance, security, etc (along the lines of what the teams at Zeppelin, Aragon and Decred are building).

Today is election day. I’m on a plane today, so I voted early, a few days ago. I cast my vote and it felt good. I marked my paper ballot with a marker (for optical scanning) glued it shut into a sealed envelope, and handed it to a volunteer who placed it in a secure case. I left with a sense of confidence that my vote had been placed, and would be counted fairly.

Unfortunately, many Americans do not have the same confidence, often for good reason. As Zeynep Tufecki wrote in the NYT last weekend in The Election Has Already Been Hacked:

“the legitimacy of an election depends on the electorate accepting that it was fair, that everyone who tried to vote got to vote and that every vote counted. Lose that, and your voting system might as well have suffered a devastating technological attack.

Unfortunately, in much of the United States, we are no longer able to assure people that none of those things has happened. A recent poll shows that 46 percent of the American electorate do not think their votes will be counted fairly, and about a third think it is likely that a foreign country will tamper with the results.”

Put more generally, America’s most important product, our democracy, is developing a trust problem.

I have been writing about trust for a long time. It is an essential ingredient for institutions (civic, corporate, etc) and also for technology platforms. It is famously hard to earn and easy to lose.

In the most recent iteration of the USV investment thesis, we explicitly call out the idea of “Trusted Brands” as a key component. This has been somewhat controversial, because — obviously — it’s premature to declare that any early-stage startup is a trusted brand. But what we mean by this is not that it’s already a widely trusted brand, but that it’s architected to be a trusted brand.

“Trusted Brands” is also controversial because in startups, things change. For example, while for a long time many considered Google (or really, insert nearly any other large tech company here) to be a trusted brand, initially because of the super useful/helpful services it provides, and then through it’s mantra of “don’t be evil” — it’s safe to say that today, many people (both consumers and b2b users) may not feel the same way.

So, “Trusted Brands” is both aspirational, and potentially fleeting.

By “architecting for trust“ we mean two things: 1) a business model where the platform and its stakeholders are aligned; and/or 2) a technical architecture that makes tampering/hacking/meddling difficult or impossible, even for the creators of the system.

On business model alignment: this one gets trickier the more stakeholders you have, and typically as tech platforms grow and expand, so does the breadth and variety of stakeholders. But core decisions can be made, early on, that align interests as much as possible — for example, see Andy’s post about our recent investment in Scroll, and how they are attempting to align interests in the publishing industry.

On technical architecture: most of the work in the crypto/blockchain space is based on this concept, and many have taken to a mantra of a “can’t be evil” as a counterpoint to the arbitrary decisionmaking that is possible in traditional platforms — this is at the heart of the “centralized vs. decentralized” debate. But even in “regular” apps, technical design decisions, particularly around how data is stored/processed/shared/accessed, can go a long way towards building trust.

What we can safely say is that we are suffering from trust problems on a number of fronts. On the tech platforms side, it’s things like data breaches, abuses of market power, shady privacy practices, harassment and abuse, etc etc. On the institutional side, it’s relevance, capacity, efficiency, technological capability, corruption, and fundamental integrity. Not a small or simple list of challenges to face.

The technology we build is really the foundation of our lives, and even the two “sides” I discuss here (traditional institutions and tech platforms) are getting blurrier by the day. Given all that, what we mean by “Trusted Brands” is that establishing and sustaining trusted products / platforms / systems / institutions / brands is more important than ever, and we believe that the efforts that do manage to earn our trust over the long term will be the most important and valuable.