►
From YouTube: Graph Day: Investing in Web3 with Josh Nussbaum
Description
Josh Nussbaum, Founder at Compound VC, gave a presentation entitled "Investing in Web3" at Graph Day in San Francisco on January 25th, 2019. Josh gives an overview of his theses and approach to making investments in the Web3 ecosystem.
Sections:
0:00 Intro
0:54 VC's Dilemma
2:18 What are Blockchains good for?
3:20 Limitations
7:45 What does success look like?
10:15 Evaluation Factors
11:53 Defensibility
12:22 Network Effects
13:53 Switching Costs
14:36 Brand
15:51 Economies of Scale
17:01 Summary
The Graph's Media:
Twitter: https://twitter.com/graphprotocol?s=20
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/theg...
Website: https://thegraph.com
#web3 #thegraph #defi
A
A
It's
been
pretty
active
over
the
last
couple
years,
so
I'm
gonna
talk
a
little
bit
about
how
I
think
about
investing
in
the
web
3
space
and
the
investment
frameworks
that
go
along
with
it,
and
most
people
probably
know
this,
but
to
clarify
so
the
VCS
dilemma,
especially
for
a
smaller
fund
like
us
that
can't
just
collect
fees
right.
You
could
delete
this
whole
slide
for
a
fund
over
a
certain
size.
A
I
can
tell
you
about
technologies
that
I
think
10
years
from
now,
we'll
all
be
using,
but
it
doesn't
really
matter
unless
you
can
pick
a
company
today
that
is
able
to
take
advantage
of
that
and
grow
alongside
those
markets,
and
so
I
put
this
this
graphic
up
here.
It's
an
example
of
the
search
engine
market.
So
in
you
know
the
mid
nineties
I
could
have
been
absolutely
right.
A
So
we're
blockchain
is
good
for
I.
Imagine
most
people
here
have
a
good
sense
for
that,
but
also,
why
should
anyone
care
what's
the
value
in
block
shins
and
so
here's
how
I
think
about
it
when
we
access
the
Internet
today,
I'm
using
our
smartphones
or
laptops,
we're
accessing
remote
servers
and
those
servers
are
managed
by
essentially
route
administrator
or
super
user
whatever
you
want
to
call
it
in
the
case
of
let's
say
Facebook
if
I
take
a
photo
of
my
iPhone
and
then
I
upload
that
photo
to
my
facebook
profile.
A
A
A
So
put
differently
where's
their
value
when
executing
just
the
part
of
the
computation
there
needs
to
be
both
secure
and
reliable
and
Nick.
Szabo
calls
this
fiduciary
code
and
so
moving
into
the
investment
theses.
The
way
that
I
think
about
it
is
how
do
we
plan
from
today,
until
10
years
from
now,
where
we
can
look
at
a
company
and
look
for
a
wave
like
different
timelines
and
objectives?
A
My
belief
is
that
the
decentralized
financial
infrastructure
are,
you
know
the
primary
use
cases
that
make
the
most
sense
where
they
can
be
asynchronous.
They
tend
to
be
higher
value
transactions.
So
you
might
be
willing
to
pay
high
gas
fees,
for
example,
and
I,
think
that's
where
the
killer
applications
could
come
from
in
the
next
couple
of
years,
and
so
the
investment
framework
would
be
to
invest
in
protocols
and
applications
that
cater
to
these
use
cases.
A
A
couple
of
examples
here,
the
only
one
of
the
three
just
to
clarify
that
that
compound
VC
is
an
investor
in
his
compound,
coincidentally
Vail,
which
is
a
decentralized
application
built
on
augur
compound
and
robert
presented
earlier.
So
you
guys
know
what
they
do
in
dy/dx,
which
is
both
a
protocol
and
application
for
decentralized
derivatives
and
so
the
second
thesis
in
order
to
reach
critical
mass
in
adoption
for
these
decentralized
applications.
A
These
end
up
converting
to
the
tokens
that
basically
help
to
power
these
protocols
that
solve
known
weaknesses
and
problems
with
public
watch
ins,
often
times
these
are
work,
tokens
and
I'll
get
into
in
a
second
sort
of
what
I
look
for
in
a
token
model,
but
they
also
need
to
be
used
often
enough
in
the
protocol
and
designed
in
such
a
way
that
they
actually
accrue
value
so
for
each
user.
That's
actually
using.
A
The
token
is
the
next
person
is
not
just
selling
it
to
a
new
user,
and
so
it
kind
of
stays
stable
from
that
perspective.
So
some
examples
and
again
to
firefight
here
we're
actually
an
investor
in
the
first
three,
so
new
cipher,
which
is
a
protocol
for
proxy
encryption,
the
ability
to
basically
re-encrypt
a
piece
of
data
based
on
certain
conditions
under
somebody
else's
private
key
that
you
own
a
new
store
yourself.
A
You're
too,
similar
to
a
SAS
company
or
a
marketplace
would
like
to
see
increasing
supply,
and
you
can
use
month
over
month
or
year
over
year
metrics.
But
so
you
have
sort
of
compounding
interest
in
terms
of
liquidity
could
be
compute.
It
could
be
storage
for
the
defy
protocols.
It
could
be
liquidity,
for
example,
and
I,
don't
know
yet
what
exactly
that
growth
rate
should
be
the
way
that
I
do
for
SAS.
A
Companies
are
marketplaces
because
we
don't
have
that
data
yet,
but
you
do
want
to
see
it
increasing
or
at
least
staying
stable
today
by
year.
Three
legacy
proof
points
that
one
the
protocol
works,
but
also
that
there's
demand
and
so
starting
to
see
kind
of
initial
data
points
of
developers
who
were
building
applications
for
end-users
using
those
protocols
and
I,
wouldn't
expect
those
applications
to
have
users
yet,
but
there's
at
least
demand
and
there's
and
there's
buzz
building.
A
A
You
know
huge
and
massive
and
thriving,
but
where
there's
protocol
development
that
happens
outside
of
the
kind
of
initial
team
people
are
working
on
applications
and
there's
a
growing
user
base
for
those
applications
and
a
growing
user
base
in
terms
of
developers
by
your
five
like
to
get
to
a
place
where
the
core
team
can
start
to
step
away.
Maybe
they're
still
working
on
it,
but
it's
not
full-time
the
team
kind
of
shrinks
in
size
as
the
protocol
moves
towards
becoming
decentralized.
A
A
So
what
wouldn't
be
good
as
if
a
lot
of
people
were
using
the
protocol
and
you
had
a
token
that
was
kind
of
glued
onto
it
and
nobody
really
needed
it,
and
so,
as
a
result,
the
value
of
the
token
wasn't
increasing
in
proportion
to
the
protocol
itself
would
be
very
hard
to
fix.
That
problem.
Number
two
is
the
token
necessary
at
all.
Do
you
get
benefits
to
having
security
tied
directly
to
your
protocol
versus
using
something
like
ether,
die,
etc?
A
Number
three,
which
is
a
little
bit
ambiguous
but
if
the
token
is
deemed
as
security
or
we
stay
in
this
kind
of
unknown
regulatory
environment,
can
the
team
get
by
working
with,
let's
say
accredited
investors
and
enabling
them
to
do
the
work
with
those
tokens
until
they
work
out
the
regulatory
piece
and
kind
of
create
or
build
in
more
of
a
trustless
way?
So
you
can
at
least
get
off
the
ground
and
get
running
and
see
what
the
issues
are
and
get
some
of
that
demand
just
as
per
the
previous
slide.
A
Don't
think
we
have
all
the
answers
here,
but
it's
defensibility
both
with
protocols
given
that
they're
open
source
and
Russell's
in
nature,
but
also
with
applications
in
the
space
that
are
built
on
these
protocols
different
than
applications
today,
where
you're,
storing
all
of
that
user
data,
and
so
these
are
the
four
tenants
of
defensibility
in
general.
I'm
not
just
relate
to
the
space,
but
network
effects,
economies
of
scale
brand
and
switching
costs,
and
so
going
to
detail
on
each
one
with
the
protocols
themselves.
A
The
way
that
I
think
about
network
effects-
and
this
isn't
me-
I've
gone
back
and
forth
on
several
years
now,
especially
with
some
more
contract
protocols
where
you
sort
of
initially
look
at.
Maybe
it's
pulled
security.
Maybe
it's
development
that's
happening,
but
then
the
argument
is
well
chain.
Interoperability
would
make
it
so
that
all
of
these
chains
are
inoperable
one
another
and
so
that
defense
ability
doesn't
really
exist
and
I've
changed.
A
My
thinking
on
this
just
last
year,
we're
composability
is
extremely
important
and
so,
as
Robert
from
compound
Bechet
earlier,
the
ability
basically
to
use
multiple
protocols
or
call
multiple
contracts
with
a
single
transaction
and
I
included.
A
quote
here
from
a
friend
of
mine
and
Jesse
Walden
wrote
a
blog
post
on
this
subject,
who
said
that
a
platform
is
composable
if
it's
existing
resources
can
be
used
as
building
blocks
and
programmed
into
higher
order
applications,
and
so,
if
you're,
using
an
application,
that's
attempts
to
use
multiple
protocol
they're
on
different
charges
or
different
chains.
A
It's
asynchronous
or
you
know,
one
transaction
executes
another
one.
Doesn't
that
can
become
an
issue
with
some
of
the
use
cases
that
I
think
are
compelling,
and
so
with
applications.
I
think
about
this
from
a
lot
of
our
marketplace:
investments
where
you
can
basically
chart
all
of
them.
They
reach
a
place
of
critical
mass
on
the
supply
side,
which
brings
more
on
the
demand
side
and
so
on
and
so
forth
and
I.
Think
in
this
scenario,
it's
the
liquidity.
A
A
Then
what
are
the
switching
costs
with
forking?
And
so
this
applies
to
protocols,
but
it
applies
the
applications
as
well
and
so
for
applications.
They
can
point
to
the
fork
or
the
original
protocol.
They
have
that
decision,
but
once
you
have
developers
or
building
applications
and
protocols
that
are
all
hooking
into
one
another,
you
get
to
a
place
where
it's
very
very
hard
and
it
becomes
much
harder
to
fork.
A
A
A
It's
a
brand
for
decentralized
apps,
in
particular
Google
example,
and
Gmail
is
my
favorite,
where
basically
Google
has
critical
mass
with
Gmail,
but
it's
in
their
best
interest
to
use
the
open
email
protocols,
because
otherwise
they're
just
limiting
the
number
of
people
that
their
users
can
email
and
it
would
basically
seed
growth.
People
would
go
to
a
different
email
application
and
so,
as
a
result,
what
ends
up
happening
is
brand
comes
through
competing
on
cost
privacy,
service,
UI,
UX
performance,
security,
etc
and,
at
the
end
of
the
day,
I
think
the
consumer
wins.
A
With
protocols
that
the
brand
that
really
exists
is
more
trust
in
the
team
and
who's,
maintaining
it
and
familiarity
I
sort
of
view
Forks
as
a
cap
on
rent-seeking.
So
if
the
protocol
is
designed
in
such
a
way
that
there
is
extreme
rent-seeking,
then
people
might
go
to
great
lengths
to
actually
fork
the
protocol,
but
I
think
it's
higher
than
people
think,
especially
over
time,
especially
before,
once
you
have
applications
and
protocols
that
are
all
hooking
into
one
another.
A
Economies
of
scale
one
target-
this
might
be
network
effects,
but
kind
of
miss,
go
back
and
forth
and
whatever
whatever
kind
of
scale
of
what
our
network
effects
internet
platforms.
But
this
interesting
thing
that
I've
been
thinking
about
recently,
where,
if
you
were
to
build,
let's
say
an
app
on
the
augur
protocol
and
you
have
some
users
and
you
have
revenue
from
those
users.
Instead
of
just
doing
what
teams
do
today
and
you
know
reinvesting
in
the
product
or
hiring
and
scaling
quickly.
A
You
can
also
go
and
let's
say
by
rep
and
participate
in
market
disputes
and
earn
more
of
that
rep
and
in
theory,
in
a
more
of
a
perfect
market,
you
would
have
the
price
of
rep
increasing
as
well
as
usage
of
the
protocol
increases.
You
can
provide
liquidity
to
those
markets
to
help
build
that
barrier
to
entry
talked
about,
and
so
the
interesting
positive
feedback
loop
that
you
can
do
with
a
decentralized
application
in
certain
protocols
that
doesn't
exist
in
centralized
web
and
you
kind
of
rinse
in
rinse
and
repeat
so.
A
And
so,
in
summary,
my
belief
is
that
success
in
the
short
term
will
be
will
go
to
those
basically
who
are
building
for
use
cases
where
you
can
withstand
issues
with
public
block
chains
today
with
longer
term
roadmaps
in
mind,
in
order
to
be
able
to
take
advantage
what
the
technology
reaches
a
more
of
a
steady
state.
In
addition
to
these
apps
and
protocols,
infrastructure
that
solves
for
these
issues
specifically
needs
to
emerge
and
is
starting
to
emerge.
I
think
that's
critically
important.
A
So
we
get
to
a
place
where
you
and
like
Lego
blocks,
used
several
different
protocols
to
solve
certain
problems,
rather
than
relying
on
a
single
protocol.
Where
you
know
one
issue
or
congestion
on
the
network
or
whatever
it
is,
could
really
hinder
development
and
those
two
really
go
hand-in-hand
over
time.
So
you
need
people
to
sort
of
build
applications,
get
get
users
engaged
in
order
to
attract
more
people,
to
build
that
infrastructure
and
to
see
what
those
problems
are.
A
What
the
best
ways
to
solve
them
are,
but
I
think
it
will
reach
a
place
and
I,
don't
know
from
timeline
perspective.
What
this
might
look
like,
I
would
say,
maybe
a
decade
or
so,
but
where
the
protocols
themselves
reach
pretty
mature
state
and
all
the
developments
end
happens
at
the
application
layer,
which
would
enable
new
applications
that
I'm,
certainly
not
smart
enough
to
tell
you
about
here
today,
but
a
couple
of
examples
would
be
uber
would
have
been.
A
You
know
very,
very
difficult
to
build
before
we
had
4G
LTE
everywhere
Instagram
until
the
camera
and
the
iPhone
reached
a
certain
point.
There
was
no
point
at
everybody
becoming
their
own
photographer
and
throwing
filters
on
what
they
were
doing,
because
the
quality
was
still
very
low
and
that's
it.
If
anybody's
any
questions,
comments.
There's
my
twitter
handle
and
email
always
happy
to
answer.
I.
Don't
think
we
have
time
for
any
more,
unless
maybe
we
can
get
one
in
anybody
has
any
questions.