►
From YouTube: Future of Smart Contract Security Audits: REKT or WAGMI
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/future-of-smart-contract-security-audits-rekt-or-wagmi/
Smart contract security audits have become a de facto requirement for Ethereum applications. However, there continue to be multi-million dollar hacks every week highlighting significant challenges with audits such as questionable quality, arguable effectiveness, unreasonable expectations, high cost, low availability and dearth of talent. This panel proposes to debate on these contentious aspects with some leaders in this space and peek into their crystal ball to see if we are REKT or WAGMI.
Speaker(s): Jonathan Alexander, Gonçalo Sá, Nick Selby, Mehdi Zerouali, Chandrakana Nandi, Maurelian
Track: Security
Keywords: Smart Contracts,Security,Audit
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
I
work
at
optimism:
I
focus
on
security
in
our
protocol.
I
previously
was
an
auditor
and
co-founded
diligence
with
Gonzalo
and
have
had
the
Good
Fortune
of
working
as
a
client
with
these
three
gentlemen,
and
not
yet
sir
Torah,
but
have
had
an
opportunity
to
get
to
know
them
really
well.
So
I
really
feel
in
my
element
and
I'm
excited
to
have
this
conversation
so
I'll.
Let
them
introduce
themselves
quickly.
If
you
could,
you
know,
give
us
your
names
and
tell
us
about
your
firms
and
what
makes
you.
B
Special
I
can
go
first,
hey
guys
and
thank
you
Richie
yeah,
if
you're
watching
yeah,
we
co-founded
consensus
diligence
almost
six
years
ago
now
or
going
to
that
me
and
John
who's
now
at
optimism.
Unfortunately,
and
the
consensus
diligence
is
a
crypto
native
security
firm
that
has
for
the
entirety
of
its
life,
done
Security
Services
and
has
also
a
product
side
which
you
might
have
seen
so
mythex
and
more
recently,
diligence,
fuzzing
and
a
bunch
of
other
smaller
tools
that
are
all
open
source
that
you
can
check
on
our
website.
C
Hi
everyone,
my
name,
is
Chandra
and
I
am
from
sartora.
Sartora
is
a
automated
auditing
company.
You
can
think
of
it
as
that
way.
What
we
do
is
we
use
formal
verification
techniques
to
prove
certain
properties,
about
your
smart
contracts
and
I'm
personally,
more
on
the
r
d
side,
and
one
of
the
things
that
we
are
focusing
on
these
days
is
how
do
you
have
more
Trust
on
the
specifications
that
you
write,
because
at
the
end
of
the
day,
that's
really
what
we're
using
as
the
ground
Truth
for
verifying
your
smart
contracts?
C
D
My
name
is
Maddie
co-founder
and
director
of
Sigma
Prime
we're
in
information
security,
consultancy
focused
on
blockchain
technology,
doing
a
lot
of
smart
contract
auditing,
as
you
can
imagine,
but
very
comfortable
diving,
deeper
into
other
layers
of
the
stack
as
John
mentioned
layer,
2
systems,
new
l1s
and
whatnot.
We're
also
the
founders
and
maintain
owners
of
Lighthouse
the
rust
implementation
of
the
ethereum
consensus
protocol.
Some
of
you
here
I'm
sure,
are
running
validators.
Some
of
you
may
be
running
Lighthouse
as
well.
We
had
the
merge
a
few
weeks
ago.
E
F
Hi
everybody
I'm
Nick,
Selby
I'm,
with
trail
of
bits.
We
are
an
audit
and
research
company
based
in
New
York,
but
people
are
all
around
the
world.
In
addition
to
audits,
we
have
a
research
group
that
that
mainly
works
on
just
sort
of
pushing
the
edges
of
of
a
bunch
of
different
Technologies,
including
blockchain,
and
where
are
things
going
next
and
we
make
some
pretty
popular
open
source
tools
like
Slither
and
Echidna,
which
probably
several
of
your
you
know,
familiar
with
thanks,
I'm
glad
to.
A
F
A
Awesome
thanks
everyone.
So
first
question
I
think
is
like
maybe
a
bit
of
a
softball
just
to
get
us
going
and
I'll
I'll
pose
this
to
Medi
first
and
then
just
let
the
conversation
get
going.
So
it's
been
three
years
since
the
last
Devcon.
What
do
you
see
as
the
biggest
changes
in
that
time?
Maybe
it's
something
you're
excited
about
something
you're
worried
about
we'd
love
to
hear
it.
D
Yeah
interesting,
let's
see,
I
think
what
I've
been
noticing
is.
The
quality
of
the
projects
that
we've
been
reviewing
has
somewhat
improved
over
the
past
three
years.
This
caveats,
obviously
we
still
get
the
occasional
you
know.
D5
projects
with
you
know,
lack
of
access
control
and
the
typical,
unsafe
and
safe
external
calls
and
re-entrances,
but
I'd
like
to
think
that,
thanks
to
some.
D
That's
been
available,
it's
been
doing
great
work
on
that
front
developers
have
a
lot
of
abilities
these
days
to
pick
up
the
low
hanging.
Fruits
contracts
are
getting
more
and
more
complex
in
the
D5
space,
particularly
some
of
the
lending
protocols
that
we've
been
reviewing
are
pretty
hectic,
but
yeah
yeah
I,
think
you
know
the
amount
of
money
getting
stolen
on
a
weekly
basis.
These
days
is
probably
greater
than
what
it
was
three
years
ago.
D
B
F
We
we
can
see
them
a
lot
more.
Clearly.
Everybody
here
has
a
lot
more
experience
in
in
finding
things
and,
on
the
other
other
hand,
three
years
ago,
I
remember
being
describing
to
board
members
of
a
of
a
pretty
large
crypto
company
about
nation-state
threats,
specifically
talking
about
North
Korea,
and
they
kind
of
looked
at
me
with
blank
stairs
and
they
were
like
well,
you
know.
C
A
A
E
E
If
we've
had
situations
I'm,
not
going
to
say,
we've
had
situations
where
things
we've
missed
have
been
found,
but
customers
we
work
with,
maybe
have
a
situation
arise
and
you
are
a
trusted
security
advisor
to
them,
you're,
going
to
Rally
to
help
them
in
the
situation,
and
that
may
be
in
discussing
what
are
the
potential
fixes
in
reviewing
fixes
and
even
talking
about
public
Communications,
and
that
is
a
I
think
if
you
are
with
a
trusted.
You
know
we
view
these
relationships
as
Partnerships,
then
that's
what
what
we're
going
to
try
to
do?
E
I
think
that
in
the
case,
in
a
specific
case
where
something
is
missed
in
an
audit
which
sometimes
like
we've,
had
some
situations
where
we'll
we'll
do
an
audit
and
then
before,
thankfully
pre-release
an
issue
is
discovered
that
was
missed
in
the
audit.
Maybe
because
there
was
another
you
know
set
of
eyes
on
it
or
maybe
there
was
internal
testing,
and
in
that
case
we
always
view
our
responsibility
is
to
do
a
very
thorough
postmortem
on
what
happened
exactly
what
was
found.
E
A
So
so
we've
heard
from
Jonathan
that
it's
I
I
think
this
is
just
like
late
to
the
preface
on
the
same
topic,
but
Jonathan
has
been
open
that
a
top-tier
auditor
can
miss
something
and
so
you're
lucky
right,
like
it
got
caught
before
it
hit
production
that
can
happen
to
anyone.
So,
let's
like
put
that
out
there
is
anybody
on
the
stage
like
actually
had
something
they've
added
be
exploited
in
a
significant
way.
I'm
curious.
B
Not
really
but
we've
had
stuff
being
disclosed
after
it's
in
production
yeah
like
I
I,
think
that,
like
we
establishing
and
we've
said
this
many
many
times
we're
not
insurance
companies
right,
so
that's
the
Baseline,
but
there's
an
ethical
and
moral
code
that,
like
that
we
uphold
to,
and
so
if
something
happens.
Obviously
this
is
also
Case
by
case
on
a
case-by-case
basis.
B
It
should
be
analyzed
differently,
because
if
it's,
if
it's
our
the,
if
the
problem
was
created
by
us
specifically,
then
we
might
react
one
way,
whether
if,
if
the
if
there
it
was
just
like
a
Miss,
we
might
react
some
other
way,
but
at
the
end
of
the
day,
we'll
try
our
best,
but
we're
not
obligated
to
anything
right.
Nor
can
we
be
because
that
actually
destroys
the
entire
relationship.
F
F
So
our
first
reaction
is
to
to
refresh
ourselves
as
to
what
we
know
about
this
project
and
then
reach
out
to
try
to
offer
as
much
assistance
as
we
can
I'm
very
very
pleased
to
say
that
the
entire
Rec
leaderboard
does
not
have
our
name
on
it
today
that
that
will
change.
But
you
know
as
of
right
now,
but
but
this
is
a
process
that
we
take
very
seriously
because
it
it
can
happen.
There
are
no
guarantees
in
audits.
F
B
F
The
the
helping
the
customer
I
mean
I.
Let
me
be
clear,
because
I
made
this
same
mistake
in
Stanford
I
don't
mean
free,
necessarily
right
like
we.
We
will
help,
obviously
for
nothing.
There
are
certain
things
that
we
can
do
as
Auditors
and
and
as
experts
in
in
the
field
where,
if
there's
more
services
required,
if
it's
fixed
reviews,
if
there's
other
things,
but
the
first
thing
we
want
to
do
is
reach
out
and
say:
hey.
We
saw
that
this
happened.
Do
you
need
any?
Do
you
know?
F
D
I
feel
so
bad
using
the
word
auditing
or
audit
every
time
I
do,
but
these
are
really
time
boxed
security
assessments.
Let's
just
all
agree
on
this,
as
John
was
saying,
these
things
are
not
bulletproof
right
bugs
will
be
missed
and
we
allocate
a
certain
amount
of
time
to
do
our
best
to
find
these
vulnerabilities
in
your
code.
But
guess
what?
If
you
give
us
double
the
amount
of
time
chances
are
we'll
probably
find
more
bugs.
D
F
And
by
the
way,
that's
that's
not
just
a
cya,
it's
not
you!
You
said
the
word
partnership
or
you
said
the
word
partnership.
People
wait
a
long
time
for
audits.
It's
a
very
important
part
of
the
process
of
going
live
with
with
a
product,
especially
a
product
where
a
lot
of
money.
You
know
if
it
goes
bad,
a
lot
of
money
can
go
out
the
door.
F
Customers
have
their
own
priorities,
customers
have
budgets,
customers
have
realities,
and
usually
it
ends
up
that
we're
not
negotiating
actually
about
money,
but
about
time
we're
not
negotiating
about
money,
but
about
the
number
of
Engineers
who
can
be
looking
at
it.
So
while
we
can't
guarantee
that
a
three-week
two
engineer,
audit
will
find
all
the
bugs
we
can
guarantee
that
a
three
week
two
engineer
audit
will
find
all
the
bugs
that
can
be
found
by
three
Engineers
by
two
Engineers
working
for
three
weeks
and
that
that's
a
different
sort
of
guarantee.
Yeah.
A
Okay,
so
I
think
I
think
Medi
set
this
up
well
in
that
by
saying
like,
like
just
the
Magics
of
what
this
is,
what
we're
doing,
how
is
it
defined
so
we're
saying
time,
box,
Security
reviews
now,
do
we
need
do
we
need
a
set
of
Standards
to
make
it
clear?
Whatever
word
we
choose,
do
we
need
to
have
a
set
of
standards
for
this
and
I'll
give
it
to
Chandra
to
to
take
a
crack
at
it?
So.
A
C
Review
well
so
you
know,
I
I
can
perhaps
speak
from
a
more
automated
auditing
point
of
view,
but
then
I
think
some
of
the
ideas
probably
also
apply
to
human-based
auditing
I.
Think
the
hardest
thing
is
to
come
up
with
what
with
the
specification
right
like
even
when
you're
auditing
like
what
are
you
actually
looking
for
I.
Think
that's
one
of
the
main
questions
that
you
should
very
carefully
think
about
right
and
you
know
I
think
one
of
the
things
that's
kind
of
difficult
for
auditing.
C
Is
it
you
it's
hard
to
be
very
precise
and
if
you're
not
precise,
then
you
kind
of
think
that
you
did
a
proof
or,
like
you,
have
some
kind
of
guarantee
that
this
bug
isn't
there,
but
I
think
you
know
unless
it's
very
easy
to
feel
like
you,
you
know
audited
really.
Well,
if
you
don't
have
the
specification
correctly
in
your
head
and
perhaps
a
related
thing
is
in
formal
verification.
There's
this
notion
of
trusted
Computing
base
and
I
think
that
idea.
C
Also,
you
know,
maps
to
auditing
like
what
part
of
the
code
did
you
audit?
What
parts
of
the
code
did
you
not
audit
right?
And
you
know
you
can
only
say
confidently
well
with
some
confidence
that
the
code
that
you
did
audit,
maybe
doesn't
have
some
vulnerabilities,
but
the
parts
that
you
didn't.
You
can't
say
anything
about
them
right.
So
it's
very
important
to
be
very
explicit
about
what
the
TCB
is
and
what
you
verified
and
what
you
checked
or
whatever
you
audited.
E
I
would
say:
I'm
a
little
frightened
of
the
word
standard
in
what
we
do,
because
I
think.
Sometimes
it
comes
from
the
place
of
people
hoping
that
we're
going
to
simplify
down
to
some
very
simple
set
of
rules,
what
needs
to
be
covered,
and
then
anyone
could
cover
it,
and
so
I
do
think
we
need
common
language.
E
What
is
their
experience?
Because
those
are
the
people
you're
going
to
be
working
with
and
and
what's
more
important,
probably
than
standards
is
agreement
with
who
who's
going
to
provide
you,
the
security
review
and
who
are
those
people
and
what
are
their
skills
and
what
are
their
ex?
What's
their
experience,
yeah.
A
A
He
said
who
odds
the
Auditors
and-
and
so
you
know,
as
a
project
and
I
experience
this
now,
as
somebody
who's
audited
before
and
understands
the
industry,
far
better
than
most
still
scary,
like
talking
to
like
trying
to
evaluate
the
auditor
like
for
the
code
that
I
have
that
I
want
looked
at.
Does
this?
Is
this
the
right
audit
firm
and
do
they
have
the
right
people
available
when
I?
It's
there's,
so
many
moving
Parts,
it's
crazy,
but
back
to
that
who
are
as
the
Auditors
like.
A
Is
there
some
way
that
we
can
that
we
can
or
should
be
holding
I,
don't
want
to
go
back
to
like
holding
otters,
accountable
and
the
skin
in
the
game
thing
that
we
can
go
around
round
about,
but
yeah
like
how
can
how
can
we
help
non-honors
evaluate
the
Otters
that
they're
working
with?
Should
there
be
some
kind
of
third-party
Watchdog?
That's
ranking
you
all
or
what,
like.
B
There's
a
I
think
it's
a
place
like
this.
A
good
plug
here
would
be
like
to
talk
about
each
trust
and
I.
Think
we
all
participated
in
the
standard
in
one
form
or
another
and
I
think
it's
like
a
dangerous
proposition,
because
what
the
the
proposition
of
each
trust
is
that
there's
levels
of
how
secure
your
code
bases
there's
like
kind
of
a
risk
assessment
of
how
your
code
base
will
look
like
after
you
have
done
certain
things
right.
So
so
this
this.
B
This
is
part
of
the
eea,
the
Enterprise,
ethereum,
Alliance
and
I
think
it
was
Tomlin
who
started
it.
I
think
it
is
a
dangerous
proposition,
but
it
might
actually
be
helpful
if
you
are
not
super
embedded
into
the
security
industry
right
again.
It
has.
It
is
useful,
but
it
is.
It
should
be
taken
with
a
grain
of
salt
because,
like
if
you
take
level
three
or
like
formal
verification
as
I'm
gonna,
say
it.
That
will
probably
be
a
disservice
to
you.
E
E
It's
very
public,
so
in
some
sense
we're
watched
yeah
very
closely,
and
so
this
idea
that
so
our
reputations
are
on
the
line
all
the
time.
All
the
time
and
honestly
I
know
all
of
us
up
here
we
lose
sleep
over
it.
Right
like
and
and
I
will
say
too,
that,
like
it
opens
up
when
we
work
and
opens
up
on
contracts
and
we've
had
issues,
and
you
know
so
we're
our
reputations
are
very
public
and
we're
all
glad
we're
not
on
the
rec
leaderboard.
And
so
we
can
talk
about
I.
E
D
E
A
Yeah
and
I
like
how
you
said,
like
you
lose
sleep
over
it,
I
think
you
know,
everybody
in
this
room
loses
sleep
about
either
the
code
that
they're
running
or
the
code
that
they're
auditing
so
should
all
go
easier
on
ourselves.
So
I
just
want,
like
I,
think
it'd
be
fun
to
get
some
questions
from
the
audience.
So
if
you
have
a
question
raise
your
hand
and
meanwhile,
while
the
mics
are
getting
handed
out,
we're
gonna
try
something
overrated,
underrated,
lightning
round.
A
A
F
It
I
was
actually
Jocelyn.
Feist
is
here,
is
the
head
of
our
blockchain,
and
he
was
saying
you
know
you
can
pick
the
tool
you
can.
You
can
pick
how
it
is
that
you
want,
if,
if
you're
not
able
to
put
down
in
English
what
what
are
the
invariants?
What
are
the
things
that
you're
trying
to
accomplish
here?
F
H
B
Expanding
upgradability
is
a
bug.
Not
always
we
went
through
this.
So
there's
a
there's
a
longer
conversation
about
this
that
happened
at
defy
security,
Summit
I,
think
that
is
available
on
YouTube,
so
I
could
rent
on
and
on
about
this
there's
also
a
bunch
of
articles
on
the
on
the
internet
about
this,
but
generally
speaking
it
you
are
just
injecting
another
attack
Factory
in
your
code
base.
Okay,.
A
C
C
You
should
be
very
careful
when
you
make
these
kinds
of
claims
and
I
think
it's
very
dangerous
to
make
these
claims,
because
you
know
the
spec
could
itself
be
wrong,
and
even
if
the
spec
is
reasonable,
I
mean
there
could
be
a
bug
in
the
formal
verification
tool
and
like
then
that's
you
know,
that's
also
bad,
and
you
know
just
because
there
is
a
specific
bug
that
you
verify
verify
your
code
against
does
not
mean
that
there's
you
know
it's
just
bulletproof
and
you
can
just
trust
it
with
your
life
right.
So.
A
A
D
Look
now:
we've
we've
we've
definitely
done
a
bunch
of
security
assessments
targeting
different
execution
environments.
Don't
get
me
wrong,
but
obviously
most
developers
are
operating
with
solidity
Viper
at
the
evm
level.
It's
got
its
quirks,
but
it
it's
kind
of
working
I'd
be
excited
to
see.
The
upcoming
upgrades,
particularly
eof
AVM
object
files
that
might
change
a
lot
of
things
with
regards
to
security
guarantees
or
assumptions
that
we
make
with
that
with
the
evm,
but
yeah
I
don't
know
I
quite
like
it.
By
now,
all.
A
E
As
as
a
you
know,
our
risk
tolerance
is
really
high
and
our
you
know
our
skin
in
the
game
is
really
high
and
and
and
our
risk
levels
are
not
well
understood.
So
it's
hard
to
get
insurance
yeah,
if
not
impossible,
for
a
lot
of
us,
so
I
think
that'll
change,
that's
gonna
change
for
sure,
and
so
that's
why
I
say:
underrated,
I,
think,
it'll
change
and
then
yeah
there'll
be
Hedges
and
insurance
and
I
mean
it
is
happening.
It's
not
like
it
isn't
happening,
but
I
think
it'll.
It.
G
A
Yeah
I
do
I,
do
like
I'll
I
will
give
one
I
haven't
given
many
opinions,
I,
don't
think,
but
I
think
that
having
somebody
try
to
price
risk
who's,
not
an
auditor
Auditors,
don't
want
to
price
risk.
They
like
look
for
bugs
right,
but
and
it's
a
totally
different
thing
to
be
in
what
is
an
actuary,
but
there
should
be
actuaries,
and
maybe
they
are
the
ones.
Maybe
they
audit
the
Auditors.
They
have
an.
F
What
we're
really
hoping
for
is
that
that
people
doing
Security
reviews
can
set
those
standards
so
that
that
the
insurance
companies
are
actually
as
passionate
about
what
they
do
that
they're
getting
into
it.
Not
just
because
oh
look
at
that,
it's
a
new
adjacent
Market
that
we
can
get
into
and
much
more
around
wow.
This
is
really
Innovative
stuff.
We
should
get
in
there
to
make
it
safer
and
we're
working
with
several
people
like
that
and
I'm
very
hopeful,
so
I'm
with
you
about
underrated,
interesting.
G
H
A
I
H
E
H
For,
for
example,
like
there
are
products
out
there
that
claim
that
they
could
like
maybe
detect
hacks
and
all
that
or
maybe
secure
your
smart
contracts.
That
kind
of
a
thing,
but
a
hacker
could
use
like
a
private
mempool
to
like
really
send
these
transactions
across
and
to
even
to
react
right.
You,
your
transaction,
maybe.
E
A
D
D
D
Who
do
we
write
that
for
that's
an
excellent
question?
We
write
that
for
our
clients
now
the
problem
that
we
may
see
quite
often
in
our
space
is,
you
know,
readers
sort
of
going
through
well
users
of
the
protocols
that
we
review
going
through
our
reports
and
not
necessarily
understanding
again
the
concept
of
a
timebox
security
assessment
in
a
lot
of
cases,
the
scope
that
we
actually
go
through
is
a
limited
part
of
the
entire
protocol.
D
These
happens
quite
often,
particularly
with
very
very
complex
systems,
and,
unfortunately,
some
users
may
use
our
security
assessment
reports
and
say
look.
This
protocol
is
absolutely
safe,
because
this
auditing
firm
has
only
found
a
couple
of
you
know,
mediums
and
lows,
and
informationals
and
they've
all
been
resolved.
A
D
Right
exactly
that's
right:
they
passed
the
audit
big
check
mark.
None
of
us
here
provide
you
know
any
big
green
check
mark
in
our
auditing
reports.
There's
plenty
of
other
firms
that
do
that,
unfortunately,
so
yeah
I
think
I
think
you're
absolutely
right.
The
audience
of
these.
These
security
assessment
report
is,
is
a
tricky
one.
D
Something
are
you
writing
it
for
a
client
yeah.
This
happens
quite
often
I'm
sure
I'm,
sure
that,
like
it
happens,
quite
often
yeah
I'll
take
it.
No,
no,
no
no
I
mean
I
mean
a
client
can
argue
on
the
severity
of
a
bug
right
and
that's
absolutely
fine.
You
know
we're
more
than
happy
to
have
that
conversation
and
be
like
okay.
Why
do
you
think
this
is
not
a
critical
like
look
I've
got
systems
of
chain
in
place
to
prevent
this
from
happening,
that
I
would
actually
drop
down
the
likelihood
of
exploitation.
D
F
Now
this
goes
against
the
trusted
advisor
role,
which
we
play
and
and
how
to
read
our
reports
or
I.
Think
all
of
our
reports
is
that
it
isn't
that
check
mark
and
what
I
want
to
see
from
a
customer
is
I
want
to
see
them
come
out
with
our
original
report,
which
we
will
not
change,
and
so
you,
as
as
the
public,
can
look
at
the
report
and
see
the
problems
that
they
faced
and
then
you
can
look
at
the
fix
review
report
which
is
separate
or
an
appendix
it's
just
it's
it's
different
and
see.
F
Okay,
you
can
actually
watch
the
progression
as
they're,
taking
the
advice,
they're
understanding,
not
just
how
to
fix
that
bug,
but
how
to
fix
bugs
like
that
from
happening
at
all
and
and
some
companies
are
afraid
to
do
that,
because
people
will
think
that
they're
not
good
at
security
I,
look
at
it
as
the
exact
opposite,
a
company
that
is
proud
to
say
look.
These
are
the
challenges
we
face,
and
here
are
the
innovative
solutions
that
we
came
up
with
to
address
them.
A
A
C
I
mean
I,
think
we
similar
reports
and,
like
Maddie,
said
right
like
we
have
the
severity
of
the
bugs,
and
we
explain
exactly
what
property
we
wrote
and
why
that
corresponds
to
the
bug
and
I.
Think
the
only
additional
thing
that
we
very
much
emphasize
is
that
you
know
like
this,
like
be
careful
that
don't
just
take
this
as,
like
the
you
know,
this.
G
H
C
I
So
disclosure
I
work
with
Jonathan
and
open
Zeppelin,
but
I
didn't
tell
about
the
question
ahead
of
time.
So
there's
no
front
running
here.
If
you
could
wave
your
hand
and
every
single
developer
in
the
space,
but
most
especially
your
clients
just
automatically
follow
the
best
practice
without
you
having
to
tell
them
ever
again.
What
would
it
be?
Yeah.
D
K
C
So
the
question
is:
do
you
want,
should
we
start
formal
verification
towards
the
end
or
do
towards
the
beginning
of
your
development?
So
this
is
a
very
interesting
question.
You
should
start
as
early
as
you
can
that's
based
on
you
know
our
experience
I
think
that's
the
right
place
to
start
thinking
about
formal
verification,
I
think
the
most
important
thing
there
is.
You
know
you.
C
It
really
helps
you
sort
of
write
your
code
in
the
most
simple
modular
way,
because
that's
really
what
is
best
suited
for
formal
verification,
and
you
know
it
just
it
automatically
just
prevents
you
from
making
certain
mistakes
and
I
think
it's
extremely
important.
Even
if
you
are
you
know
no
matter
what
kind
of
verification
technique
you're
using
the
earlier.
You
start
the
better
and
along
the
same
lines.
You
know
writing
your
specs
out
in
English
and
also
like
you
know,
gradually
making
them
somewhat
more
formal,
I.
C
A
Think
there's
like
I
like
the
shift
left
security
meme,
which
is
like
it
basically
just
the
idea,
if
you
think
of
your
time
and
your
process
is
moving
from
left
to
right.
Writing
writing
your
code.
Then
writing
your
specs
and
tests
is
doing
it
on
the
right
hand,
side.
So,
the
more
that
you
can
do
any
of
these
things,
your
specs
formal
verification,
test.
Writing
earlier
in
the
process.
Generally,
the
better
your
outcome
will.
J
So
I
have
a
question
for
you:
I
think
Jonathan
and
Nick
were
touching
upon
it,
but
crypto
is
a
very
narrative
driven
industry
in
general
and
if
we
zoom
out
a
little
bit
and
get
outside
of
the
security
Eco
Chambers,
what
are
some
narratives
that
you
want
to
see
and
what
are
some
narratives?
You
want
to
correct
that
are
floating
out
right
now
in
terms
of
security.
Did.
A
J
Yeah
I
was
going
to
say
if
we
make
an
assumption
that
security
Community
within
crypto
is
is
on
the
on
the
table,
and
there
is
a
broader
developer
Community
outside
as
well,
who
are
all
developing
building
the
tools
who
are
susceptible
to
certain
narratives.
What
are
some
narratives
that
are
floating
around
around
secured
around?
How
people
see
security
audits
around
how
people
see
Security
in
general
that
you
want
to
take
the
chance
to
like
correct
if
you
see
anything
wrong?
What.
A
J
D
B
E
L
C
A
Make
it
more
General
I,
like
we
sort
of
I
I,
think
I
think
I'll
get
we
will
get.
This
is
like
like
just
generally,
we
have
some
new
alternatives
to
audits
that
have
emerged
giant,
bounties
and
and
like
code
Arenas
and
Sherlock
doing
these
like
auditing
competitions
that
are
a
little
bit
like
a
Time
boxed
Bounty
program,
so
yeah.
F
Is
a
holistic
view
of
of
all
of
The
Code
by
by
Engineers,
who
are
deeply
and
intimately
involved
with
the
code,
to
the
same
extent
that
that
your
internal
people
are
but
they're,
seeing
it
from
through
a
different
lens
they're,
seeing
it
through
the
lens
of
people
who
have
literally
watched
everything
that
could
go
wrong,
go
wrong
and
and
being
able
to
see
mistakes
in
everything
from
documentation
to
to
just
your
overall
maturity.
It's
a
different
set
of
things.
F
If
you
want,
if
you
want
to
find
specific,
bugs
and
fix
those,
that's
great,
there's
other
things
that
are
that
are
outside
the
the
general
scope
of
what
we
do
in
a
Security
review.
I'm,
not
suggesting
that
that
audit
or
Security
review
is
the
the
be-all
and
end-all.
But
it's
also
different
from
a
lot
of
things
that
I'm
seeing
out
there
and
as
far
as
automation
goes.
F
A
Else
quickly,
we're
running
low
on
time.
Sorry,
sorry,
sorry,
no!
No!
That's
I
meant
on
the
stage
like
if
anybody
wanted
to
all
right,
I'm
gonna
be
selfish
too
there's
something
in
the
time
we
have
I
really
want
to
plant.
This
idea
as
much
as
possible
is
that
it's
not
the
auditor's
job
they're,
not
selling
you
Security.
A
D
M
B
Fuzzing
makes
a
lot
of
sense
all
the
time
it's
we're
going
to
like
the
shift
left.
The
shift
security
left
narrative
and
all
that,
like
you,
should
use
all
the
tools.
Literally
you
you
should
write
specs.
If
you
have
specs
fuzzing
will
work
better
right,
so
I
I,
don't
yeah,
you
should
just
do
it
all
the
time
use,
Foundry
and
use
all
the
other
tools
use
a
kidney
use
Harvey
by
the
way,
I
forgot
to
say,
I've
been
announcing
this
the
entire
week.
But
this
is
the
panel.
B
B
J
C
I,
just
well
yeah
I,
guess,
I
to
add
to
what
Gonzalo
said:
I
think
using
tools
is
actually
good,
so
fuzzing
makes
sense.
To
me,
I
mean
you
know
again,
it's
not
a
guarantee,
but
you
know
I
think
it's
just
like
good
software
engineering
right
like
you
write
code
and
you
want
to
write
tests
and
you
want
to
do
fuzzing
and
you
want
to
write
specs,
and
these
are
all
good
software
engineering
practices
and
I.
Think
they
also
just
are
they
carry
to
this
domain
as
well?
So
it
makes
sense.
F
The
one
the
one
comment
about
that
you
just
made
well
both
of
you
like
that:
the
Declaration
of
things,
the
ability
to
set
forth
the
spec
and
then
and
then
fuzz
around-
that
that's
really
important.
That
first
part
is
what
Jocelyn
and
and
Gustavo
are
going
to
be
doing
tomorrow,
there's
going
to
be
a
two-hour
workshop
on
how
do
you
declare
these
things?
How
do
you
actually
set
out
and
and
describe
in
variants,
and
how?
F
A
Just
to
be
fair,
I
know
like
we're
at
a
time
by
this
timer.
Let's
give
every
speaker
like
30
seconds
to
sorry
all
right.
So
we
started
the
questions
way.
Early
we've
got
tons
of
time,
I
should
have
read.
The
manual
did
Brian
I
know,
Brian
had
his
hand
up
at
one
point
and
I'll
get
you
please
just
get
just
like
I'll
I'll,
repeat
it
through
the
mic,
so
go
ahead.
F
F
D
I
I
think
it's
gonna
really
depend
on
the
writing
style
of
of
the
security
firm
that
you
engage
with,
but
it
is
something
I'd
like
to
think
about
a
bit
more
yeah.
Perhaps
we
could
parse
some
of
those
reports
into
a
readable
format
or
a
machine,
readable
format
that
shouldn't
be
too
hard
to
do.
We
write
a
report
in
reports
in
latex,
so
it
should
be
pretty
trivial
for
us
to
do.
G
C
So
try
actually
we
do
have.
We
have
been
working
on
a
related
things,
so
I
don't
know
if
you've
ever
heard,
like
there's
things
like
deoxygen
or
the
oxygen
I,
don't
know
how
to
pronounce
it
and
like
there's.
Also
Nat
spec
is
another
similar
Library.
So
the
nice
thing
about
you
know
if
you're,
if
you
have
a
formal
spec,
it's
actually
a
little
bit
easier
to
like
sort
of
convert
that
to
a
format,
because
you
can
annotate
your
code
and
then
you
can
automatically
generate
some
kind
of
a
formatted
report.
N
Hey
guys
Kevin
over
here,
Hey
friends,
so
having
come
from
sort
of
the
security
side
and
now
being
protocol
engineer
and
founder
I'm
wondering
about
this,
this
line
you
tread
as
an
author
of
being
very
slow,
methodical.
You
know.
Heavy
testing
core
protocol
must
be
super
secure
to
now.
Okay,
now
I'm
wanting
to
move
a
bit
faster,
maybe
their
integration
contracts
or
something
that's
not
in
my
core
protocol.
N
A
I
B
O
Okay,
cool,
it
might
come
off
as
somewhat
pedantic,
but
I'm
curious,
looking
at
the
different
way
that
auditing
firms
do
severity
or
impact
and
then
difficulty
slash
likelihood
I'll
be
honest,
I
like
when
I
prefer
likelihood
so
that
it's
like
difficulty
is
low.
When
likelihood
is
high,
so
I
was
just
wondering
you
know
High
likelihood
and
high
impact
would
equal
High
severity.
Have
you
seen
clients
get
confused
about
this
different
and
without
being
overly
like
strict,
as
the
industry
is
still
developing,
I'm.
Also
curious
about
like
how
we
might
classify
things
trail
of
bits.
O
Has
a
nice
classification
swc
seems
like
outdated
and
not
updated
as
well
as
or
maybe
it
could
be
going
forward?
Are
there
things
that
we
can
do
as
an
industry
to
improve
and
start
to
I
hate
to
say
solidify,
but
structure
our
information
architecture
a
little
bit
more,
so
that
clients
can
understand
when
they're
getting
multiple
audit
reports
and
reduce
confusion?
I.
D
Think
I
think
it's
yeah,
it's
a
great
Point,
as
you
said
well
for
us
for
us
at
CP,
a
high
likelihood,
high
impact,
critical
and
I
think
we
all
use
perhaps
similar
types
of
risk
rating
matrices
it.
It's
probably
beneficial
if
you
could
standardize
on
on
how
we
would
write
severity.
So,
as
you
said,
it's
typically
likelihood
of
exploitation,
impact
of
exploitation,
but
there's
different
levels.
So
we
only
have
we
got
four
of
them
at
CP,
so
informational,
low,
medium,
high
and
critical,
that's
actually
five
but
yeah
I.
Think
I.
D
P
I'm
going
to
give
you
a
bit
of
a
left
field
question
so
there's
been
a
few
regulatory
proposals
that
includes
software
security,
best
practices
in
The
Proposal.
What
sorts
of
standards
that
are
driven
by
regulations
could
be,
do
you
think
could
be
damaging
to
the
space
and
what
ones
do
you
think
could
be
good
like.
A
E
I
think
I
I
don't
know
if
it
goes
to
like
the
intent
of
your
question
having
to
do
with
structure
of
code.
I
think
we
all
know
we're
concerned
about
regulations
that
would
impose
requirements
on
protocols
to
be
able
to
block
certain
parties
as
an
example,
so
I
think
the
biggest
a
lot
of
our
concerns
are
around
regulations.
That
would
have
a
requirement.
So
I
don't
know
if
that
goes
to
your
thought,
about
the
question
having
to
do
with
specific
processes.
B
E
I
think
that,
as
an
example,
having
worked
in
security
before
and
in
the
in
the
cloud
space,
the
sock,
2
standard
and
actually
I
believe
it
has
a
lot
of
really
good
aspects
to
the
software
development.
The
secure
security
focused
processes
of
your
software
development,
life
cycle
and
I
think
those
are
good
practices
and
if
teams
were
transparent
about
the
processes,
they
follow,
I
think
that's
healthy
and,
if
held
to
a
certain
standard,
all
those
things
always
have
downsides
in
terms
of
the
effort
that
goes
into
auditing
them
and
proving
them.
But.
F
Yeah,
the
life
cycle
of
Regulation
is
really
tough,
getting
getting
regulators
and
government
officials
to
understand
the
key
areas
they
have
a
goal
of
what
they
want
to
accomplish,
but
usually
they're
they're
rather
far
behind
the
technology.
I
think
it's
up
to
us
everybody
here.
We
certainly
do
this.
I
bet
everybody
else
up
here.
Does
this
we
spend
a
lot
of
time
talking
to
Regulators
about
what
is
possible
and
what
isn't?
D
For
clarifying
Brian
yeah,
that
makes
a
lot
more
sense.
Just
to
give
you
guys,
maybe
an
exotic
perspective.
I
was
catching
up
with
some
of
the
Regulators
in
Australia
a
few
weeks
ago,
and
this
is
exactly
what
they
were
asking
for.
They
said
what
should
we
be?
You
know
requesting
from
projects
to
do
in
terms
of
security
practices
in
terms
of
security,
development,
secure
development,
and
you
know
what
should
we
be
regulating
in
the
space,
so
I
try
to
sort
of
convince
them
to
go
down
the
educational
part
and
and
yeah.
D
This
is.
This
is
spot
on
I
think
it's
certainly
something
that
is
happening
at
least
in
Australia.
These
people
are
starting
these
conversations
and
are
starting
to
realize
the
need
of
you.
You
can't
enforce
these
things
on
projects,
but
at
least
you
can
have
these
set
of
guidelines
and
point
your
users,
your
you
know,
citizens
to
these
guidelines
and
get
them
to
demand
these
standards.
These
set
of
minimum
requirements
from
the
projects
they
interact
with.