[Music]
hey everybody great to see you all here
thanks for coming out I'm Jack Sanford
I'm the CEO and co-founder of Sherlock
Sherlock is one of the largest audit
contest providers in the space and today
we're going to talk a little bit about
the most common bugs found in audit
contests so if you're a protocol
developer or if you want to become a
protocol developer one day you are going
to be ahead of 90% of other protocol
developers just by being aware of these
10 common
bugs so just a quick intro on audit
contest and why you should care um audit
contests have become and are becoming
one of the most popular ways to secure
smart contract code before deploying a
protocol to mainnet uh there's been 625
audit contests run uh the most have
happened this year of any years so it's
really taking off 36,000 vulnerabilities
found 36 million in prizes have been
paid out to thousands tens of thousands
of Security Experts people who are
learning to be Security Experts all from
finding bugs in these audit contests and
as you can see the biggest teams in the
space are using audit contests all of
these teams have done an audit contest
this year in order to secure their
code so what is an audit contest
essentially the goal is to find bugs and
code usually critical bugs bugs that are
going to cause losses for users on
mainnet you start with a pot of money
you say hey here's 100K or in some cases
here's a million dollars and we're going
to pay people based on the bugs that
they find and anybody can participate so
it's a really great way to onboard to
crypto really great way to onboard to
web 3 security participating in audit
contests and depending on the severity
of the bugs you find so if they're
critical severity you're going to get
paid more for them if they're super
unique and other people don't find them
you're going to get paid more for that
and if you find you know three of the
four bugs that are in that protocol
during that audit contest you're going
to get paid a lot of money for that so
really cool thing and we're going to rip
through super quickly the top 10
vulnerabilities that are found in audit
contest these
days so number one first depositor
inflation attack in ERC 4626 volts this
is a super famous attack really annoying
because anytime you deploy a new Vault
um on a blockchain you're essentially uh
exposed to this attack um because the
person who puts in the first deposit can
essentially put in such a tiny deposit
that it causes sort of a rounding issue
and then all the deposits after that are
a little bit messed up and the first
depositor can steal funds that way and
kind of Dos the The
Vault second one using transfer instead
of safe transfer so just using the
transfer function in solidity doesn't
actually check the success or failure of
a transfer and it can also allow for
really bad things like re-entrancy with
non-standard tokens such as
usdt number three missing validation and
admin checks so let's say you only want
the owner of a contract to call a
function or someone on a white list to
call a function a lot of times there's
so many functions you just forget you
just forget one essentially or you
forget to check for something that you
meant to check for and that's what
Auditors are here for and they're really
good at finding that stuff um so this
happens more often than youd
think okay missing check for active L2
sequencer so essentially if you are
deploying a protocol on top of an L2
like arbitrum or optimism um sometimes
the sequencer goes down not very often
but it could happen in the future and it
could happen for long periods of time
and if you're a derivatives protocol or
something where real-time information is
super important malicious actors can
take advantage of stale prices because
of the sequencer being down
number five the classic re-entrancy very
first major vulnerability ever in
ethereum the Dow hack um basically there
are certain functions where essentially
you can continue the execution outside
of the function and call that very same
function again and this can cause all
kinds of problems there's a bunch of
different like surface area for what
these um vulnerabilities can do but I'm
sure a lot of you have heard of
re-entrance C
already Beyond transfer rebasing tokens
so if you want your protocol to be able
to handle any token out there um or even
a pretty General set of tokens a lot of
them are non-standard a lot of them
don't conform to you know things that
you would think that they conform to and
so smart contracts can get completely
dosed or or um funds can be lost because
of these tokens um having non-standard
behavior with your
functions so rounding Precision loss
issues this one has become really famous
in the last 12 months even if something
is off by a couple of way or you know to
the 18th 17th decimal place you can have
major issues because of the way that
solidity essentially or the evm
essentially doesn't have floating Point
arithmetic so it truncates things it it
rounds things a little bit and that can
cause a lot of issues um hit in the last
three really quickly here using spot
price uh instead of t-w and Unis swap so
this is something that I think we've all
seen price manip ation attacks where
someone um basically inflates the value
of a certain currency in a Unis swap
pool for even one block and then does
some attack using a flash loan and then
it goes back down so that one is really
common uh less common these days
thankfully incorrect implementation of
upgradeability so essentially you want
you want your contracts to be able to be
upgraded and it turns out you hardcoded
something in an initializer you
hardcoded something in the Constructor
and you can't actually upgrade your
contracts and you only find that out
later so that's kind of annoying but not
too big of a deal unless it's uh unless
the initial deployment of your contracts
is super
critical last one no slippage check in
custom vaults and pools so ERC ERC 4626
is great use you know standards whenever
you can uh when you're developing in
solidity um because if you have
non-standard pools you can actually have
um your user sign up to get a trade done
at one price and then at the very next
block or the very next execution um that
price is completely different and it can
be off by a massive amount of percentage
points so your users can get really into
trouble if you don't have slippage
checks on your functions there so that's
the whole talk if you're looking to
become a protocol developer check on
these 10 things before you send your
protocol to Audits and you'll be ahead
of 90% of the other developers out
there thank you Jack
I see a question over
there um when when would you do an audit
contest would it be like after you've
done an audit or before you do your
first audit like or instead of a regular
audit what what's the goal there yeah
it's a great question if you can do
multiple audits I would normally say do
the audit contest last because you get
300 people it's a little bit um there's
there's more operational um complexity
with it because you have to deal with
300 people you know Sherlock and others
will D duplicate the issues for you um
so if you can do a traditional audit or
two before that that's even better
because you get to have kind of
consultation with somebody and really
fix a lot of the things early on and
then when you're like hey I think this
thing's ready to go to mainnet do an
audit contest and you'll find all the
other stuff essentially that's the goal
hi um are there any standard protocols
or platforms for holding these contests
that you can recommend yeah so I'm the
CEO co-founder of Sherlock Sherlock is
one of the the main ones so I'm
obviously very biased um but there's
Sherlock there's Cod Arina there is
immuni does them as well now there's a
platform called Cantina Cod Hawks hats
so there's a few platforms out there
thank you
any other questions oh we have one
here thank you a is very
expensive so what is uh your suggestion
for
small uh dab with the very tight boxes
thank you yeah um if you're if you have
a tight budget uh I would say just try
to keep your contracts as simple as
possible every line of code is going to
cost you money uh when it comes to the
auditing phase and you really want to
pay per line of code like essentially
you need to pay for the best people
because those are the people who know
how to hack contracts and those people
exist on the black hat side like the bad
guys so you need to make sure you're
paying for the best good guys as well to
ensure that you find those
vulnerabilities before you go to mainnet
so if you're kind of bootstrapping just
try to keep your code as small as
possible as simple as possible use other
code that's already been audited if
possible um and when you actually do do
an audit don't go for the cheapest
provider because you really want to get
that top talent even if you have a small
code base