Loading video player...
Today we have Shashank Agrial who is the
head of security at base.
>> Everything that is found internally,
everything that is found externally, all
of that needs to be fixed in time before
any of our contracts upgraded. Anything
that we want to launch on chain, we have
to be absolutely sure.
>> Coinbase kind of built an in-house MPC
library, right, and open sourced it
recently. And we want people to take a
look like if there is any issues that
that anybody finds, we would love to
know about them. There's also a bounty
associated AI tools. What are your
thoughts on
>> once in a while they'll be able to catch
something good on a general day-to-day
basis wouldn't do very well.
>> Controversial opinions on a web 3
security topic that you'd like to share.
It might be easier to attack one of your
off-chain pieces than your onchain
pieces. And people would always go for
the weakest parts in your security
posture.
Thanks everyone for joining today.
Welcome to the web3 security podcast. Um
today we have Shashank Agraal who is the
head of security at base and responsible
for a lot of the security of the onchain
development and integration of Coinbase.
Um, I'm sure a lot of you have heard of
Coinbase, one of the world's biggest and
most well-known crypto companies. Uh,
custodies over 400 billion of assets,
earns more than 5 billion in revenue
annually. And of course, base um the
blockchain developed by Coinbase, uh,
which is one of the biggest blockchains
in the world, over 7 billion of TVL. Um,
so yeah, it's really great to have you
on, uh, Shashank. Thanks for joining.
>> Thank you for having me. I'm really
excited to be here.
>> Awesome. Well, looking forward to
getting into your background and um
talking more about how you made it to
the position that you're at today.
>> Yeah, sure. Uh so I grew up in the north
part of India and um I got into
programming
sort of at an early age. I think I was
maybe in my fifth or sixth standard and
uh we we we initially started with
writing some very basic programs in in
basic uh so like adding numbers,
subtracting numbers that kind of thing.
Um and I think from fifth standard to
like 10th standard uh we were just doing
that like very basic programming in
basic. Um I don't think I learned a
whole lot in that period. Uh and and but
and but but got comfortable with
computers to some extent like I was
still a little scared um of them like uh
in the sense that maybe I hit a key and
like it breaks the computer something of
that sort. But then in um in 11th and
12th standard is when I kind of uh began
to learn a lot. So I I started learning
C, C++ uh started coding in in in in
that language and uh yeah that was a
period I would say I kind of learned new
concepts learned about uh
object-oriented programming. Yeah. And
and started to write some more complex
programs.
Yeah. So that was my start of computer
programming.
>> Got it. Got it. And did you have I don't
know the equivalent of high school but
were you were you programming in high
school and then that kind of led you to
uh university or or how did that go?
>> Right. Yeah. Similar. So I
high school I think in the US it starts
from 9th standard right? 9th 10th 11th
and 12th is like high standard school in
in the US. Yeah. So that's when like I
said before that's when I did uh so 9th
and 10th was still basic then 11th and
12th was uh uh CC++ and and then at uh
in my undergradu uh I was exposed to a
whole bunch of programming languages.
Yeah C++ of course Java some scripting
languages uh Python, PHP and and so
forth. And we did some did some graphics
too a little bit of AI too. All of that
got exposed to various different things
in computer science.
>> Yeah. Awesome. Awesome. And where so I
know you had a lot of kind of academic
background. Um at what point I know you
were in India. At what point did you
come to I guess the US and and continue
that education?
>> So I came to the US for my PhD and uh uh
which was from Urbana Champagne. Um
>> and it was uh it was in cryptography.
So core cryptography. So very very
theoretical kind of fundamental research
in cryptography.
Um I I studied uh uh or did research on
uh things like multi-party computation,
zero knowledge proofs, different types
of encryption schemes. Um like identity
based encryption, attribute based
encryption, functional encryption. So
we're kind of designing these schemes
and uh proving mathematically proving
that they are secure under a certain
like attacker model. Um yeah, and I was
also very interested in in I I I began
to get interested in the in the
blockchain space and I read some u some
like foundational papers like the
original Bitcoin paper uh and and some
other papers as well and I was
interested to do more research but uh my
my adviser thought that this whole thing
was a scam. Um and probably still thinks
so. Um so during my PhD I did not do a
whole lot of research in in web 3.
basically uh it was still very much
focused on core cryptography.
>> Yeah. Got it. And and what was the
impetus to focus on cryptography? I mean
I try to read some of your your thesis.
You know we're talking really deep kind
of cryptography primitives. Where did
you get the itch to like get deeper into
that side of things?
>> I think uh the the the primary
motivation came from uh a course I did
in my undergrad uh theory of
computation. Um and in that course we
learned about uh tuning machines and uh
different class of complexities uh P and
P and those type of things and uh and
they were very interesting to me very
interesting uh like from a foundational
perspective what can be solved what
cannot cannot be solved what is known to
be solved efficiently what cannot be
solved efficiently so that sort of story
got me into cryptography and uh like
some some core cryptography concepts,
concepts of like oneway function and and
generate generating pseudo randomness
and like that that you can prove
something in zero knowledge. Those
concepts are also very fascinating to me
and and my my research kind of built on
top of that.
>> Yeah. Got it. Got it. And so from your
PhD, you decided to get out of academia,
get into kind of the more, you know,
commercial, go to a company basically.
What is it like, you know, being a PhD
and looking at kind of all the
commercial applications of cryptography?
Are there a lot of companies that are
kind of building their own primitives
and hiring cryptography researchers or
was it something where it's really hard
to get a job in that field? Some I I
would say not a whole lot, but but some
companies do hire cryptographers uh and
uh and maybe a small number of
cryptographers like one or two. And uh
when I graduated, Visa was trying to
build actually a whole cryptography
research team. So they actually were
starting uh their own like research
division and they wanted to bring uh uh
some researchers on cryptography,
security, AI, machine learning, all that
kind of stuff. They they they figured
out that these were the areas most
important to them. Um and they wanted to
grow in those areas. Uh so they started
hiring researchers in these areas. So I
was hired as a cryptographer. True. And
then while I was there I began to do
research on a number of things that I I
think would be relevant to the company
could find use at the company. Um but
still this was very much in the research
domain. So we would you would write
research papers, you would publish them
and attend conferences and like some of
these things were patented as well by
the company. Um, so it was still very
much research mode and then we'll kind
of present the results to to various
teams at the company and and and see if
if they're interested in implementing
one of those things in their products.
>> Got it. Got it. And what would you say
are like the biggest applications of
cryptography for Visa? You know, I know
I've heard of Visa. I know they do tons
of payments. They obviously have a whole
credit card fraud network, all these
things. And where does the kind of
cryptography come into it? So there is
there is basic things that I guess every
company does uh uh encrypting data at
rest um doing all sorts of uh signatures
setting up trust uh certificate
authorities um all of that like standard
cryptography stuff uh most companies do
and I think Visa does as well um and and
beyond that uh they were interested in
uh uh things like multi-party
computation How can we compute on data
by keeping the data distributed? uh
keeping the secrets distributed, right?
Uh uh and more recently, I think they
are interested in postquantum
cryptography. Once attackers have
quantum computers, how do we protect all
of this? Right.
>> Got it. Got it. Yeah, that makes sense.
Um
>> and back then they were also interested
in uh I mean still do um they were also
interested in crypto meaning
cryptocurrencies and and at Visa I I
began to do like proper research in in
cryptocurrencies. So I initially it
again started with kind of getting
familiar with the area leading a whole
bunch of research papers. Um and then I
started to like apply
things that I knew in cryptography to
cryptocurrencies to make them more
private, more scalable and and so forth.
>> Got it. Got it. Okay. So this was where
the cryptocurrencies started coming in
because cryptography cryptocurrencies
not not the same thing, you know, very
very different. Uh but maybe a little
bit of overlap. Uh okay. I guess you
started getting into cryptocurrencies
at Visa and then what was the journey
like from there?
>> So after Visa I was at Western Digital
uh for a couple of years. Um and uh at
Western Digital it was again very
interesting. So my my first year was
mostly about uh the kind of standard
cryptography that people are familiar
with discryption for instance or like uh
making making sure that you have uh
memory integrity that that kind of
stuff. uh but the but in the second year
so you would you wouldn't or or like
anyone wouldn't expect a company like
Western Digital to worry about
cryptocurrencies but uh when I was there
some new currencies came out that were
based on proof of space
>> uh and uh Western Digital began to think
what does it mean for them? Can they can
they build some specialized storage
devices that help people mine faster for
instance, right? Uh um and I was the
person there who already had some
background in uh um blockchain. So I
began to study these new types of
blockchains that were based on proofs of
space and in particular I I spent time
on Fcoin and Chia and they had their own
like uh very different designs by the
way. Uh yeah, so I I kind of continued
to learn uh about crypto and and
continued to do more research there. Uh
again published some some papers and
stuff like that. Uh and and then finally
after Western Digital I I came to
Coinbase.
>> Got it. And what was the you know how
are you thinking about the move from
Western Digital to Coinbase? Obviously,
Western Digital, massive company, you
know, probably decent job security and
now Coinbase, you know, even a few years
ago was still seen as like, okay, you
know, this is deep in crypto
cryptocurrencies. Um, you know, how did
you think about that move? Did you did
you see it as risky or risky? No. Uh, I
I I have followed I've been following
Coinbase for quite some time. uh and was
very interested, very excited to work
for Coinbase. Um so for me it was kind
of like my my interest in crypto was
growing and uh I Coinbase felt like a
natural place to be. Uh of course
there's like some amount of risk in this
whole space. Um and I was I was fine
with that.
>> And what did you join Coinbase to do
initially? So initially um it was it was
kind of a research role uh to to build
like a research team and and uh uh kind
of try to stay ahead of the of the game,
right? Uh understand what what new
blockchains are being built, new new
consensus algorithms that that are
coming and and study new types of
attacks and and and so forth. Um which
we continue to do. And uh then at some
point I I began to look into the
security of onchain development at at
Coinbase uh and uh base. So I was
involved in base from the very early
stages. Um and uh BAS is has of course
been a big driver of uh onchain
development uh at Coinbase. Um so now we
have the base chain and we are
responsible for securing the chain and
then anything that is built on top of
the blockchain. Uh we we are responsible
for the security of those things as
well.
>> Do you split time between base and
coinbase? Are you like 100% focused on
base now? What does that look like?
>> I would say um so uh Coinbase as a whole
is is moving you could say more and more
on chain. Um so uh initially
most of the onchain development was kind
of was kind of uh mostly in base or or
like around base but uh now other parts
of the company um are doing more onchain
development too. Uh so I guess for the
team still base most of what we do is
kind of still focused around base but
but uh we work with other teams as well
um to make sure that their onchain
development is also secure.
>> Got it. Got it. Okay. And I know we've
had uh you know a few guests on this
podcast so far. One who was also head of
security at base for a while uh Antto
from IEN. What was that? Were you were
you and he working together at a certain
point or uh did you know each other? So
he was part of my team at one point.
>> Got it. Okay. Okay. Very cool. And how
do you kind of keep up with, you know,
do you keep up with the latest
cryptography developments? you know, how
do you balance doing a day job that's
split between bass and Coinbase and
potentially keeping up with, you know,
some of the topics that you were focused
on um during your PhD?
>> It's hard now, honestly. Um I just don't
have enough time. So, am I up to date
now on like uh the the areas that I do
that I used to do research on? Uh not
really. I'm not I'm not that up to date.
like if if if something if if a certain
uh cryptography primitive becomes
popular or like people begin to adopt it
then I would come to know about it but
it's uh not possible for me anymore to
like keep up with all the research that
happens um in in those areas that I used
to work on.
>> Yeah. Yeah. Of course, that volume has
got to be insanely high,
>> but at the same time, we have a very
solid uh internal team that that works
on applied cryptography. Um, and we work
with them u on a on a day-to-day basis.
So, so that gives me that gives me an
opportunity to like stay somewhat up to
date. Uh, so multi-party computation in
particular uh is is very important for
us. uh um we we use it to secure our
keys in in our internal um key
management system. So um that that is a
very cryptography focused thing that
that we do.
>> Yeah. Yeah. I mean maybe we can talk
about that now. I know that you Coinbase
kind of built an in-house uh MPC
library, right? And open sourced it
recently. Uh what can you say about
that? Yeah, I mean we we uh open source
the core cryptography components of of
that uh of that library u and we and we
want people to take a look like if there
is any issues that that anybody finds we
would love to know about them. there's
also a bounty associated with the with
the with the library. Um and and we want
people to use like internally we have a
very very solid very comprehensive
process for building out these uh
cryptography libraries. Uh like we have
a team that that does the theory, we
have a team that does the review. That's
my team. Um and then uh we have people
implementing it. We have people
reviewing it. So it it goes through
various cycles of research and
development and like reviews and
everything. Uh so it's very well
hardened uh and and uh and and not not
every company uh espec especially
smaller ones would have the resources to
like do this kind of work right uh in in
this depth and in this detail. So if
people should uh people could use this
if if they want to uh and if they find
some problems you're happy to know and
fix it.
>> Oh that's awesome. I know that that's
one of the, you know, creating your own
cryptography is is one of the most
hardcore kind of things you can do as a
company. I think I remember reading
about PayPal trying to do it back in
2001 and they're like, "Man, no one
should ever attempt this." Basically,
>> and it's not a good idea either. Like,
uh,
it's hard and also uh it's it's very
easy to make mistakes and even a small
mistake would be undetectable. So yeah,
it's it's uh uh no one no one should try
to roll out their own cryptography
basically kind of a well-known thing.
>> Yeah. Yeah. Exactly. Exactly. Um and why
did you feel or why did you know the
security team at Coinbase feel the need
to create its own MPC library? Like what
was there before and why wasn't it good
enough I guess? So our uh I mean there
is a whole lot of research out there on
MPC like if you uh if you look at uh
various conferences and and various
papers that are put online there's a ton
of research happening in MPC but uh it's
not it's not possible uh and it's not
even a good idea to just take a research
paper and implement it because a
research paper wouldn't even provide you
all the details that are needed for for
an implementation. like a research paper
is more about the research like what new
is being added to what is known. So we
we either if we if there's a business
need for a certain type of cryptography
protocol uh if it exists we take that if
it doesn't exist we would have to uh
write it down and and prove it and then
we would create a spec from it which
would have each and every step of the
protocol written down in great amount of
detail. uh like a research paper
wouldn't care to say if this has to be
uh 64 bits or 128 bits or 256 bits like
a research paper to that level of detail
but we have to so uh we take the paper
um if we if there is no paper we write a
paper uh then we uh write down a spec
that goes into each and every detail of
the of the protocol um and the the paper
the spec everything is reviewed uh and
and uh someone tries to implement it.
>> Interesting. And you said your team is
kind of the reviewing team. Where do you
come in? Do you come in after the
implementation? Do you come in after the
spec?
>> We come in after the spec. Um so uh we
have uh uh we have professors who work
with us uh as consultants and they help
us review these uh specs and and the the
theory behind it.
>> And what's the you know what's the
impetus to open source? Is it, you know,
part of it maybe is wanting to give back
and kind of, you know, create this
public good. Is another part of it
actual actually the practicality of
like, hey, we want people to try to find
bugs in it,
>> right? Yeah. Both. Uh, so like I said
before, uh it's hard for someone
especially like smaller teams to do all
of this on their own. So if they need
certain cryptography primitives, they
could use this open source library. Uh,
and if there are bugs, then we of course
would like to know and and award a
bounty for that.
>> What's your, you know, I don't want to
get too controversial here, but there's
been a lot of conjecture that certain
cryptographic primitives have had, you
know, government back doors and that
sort of thing. What's your opinion on
all that?
>> Yeah, it's uh I I don't know. Uh I have
I've heard about and read about a number
of things. I I I don't I don't know what
to say there.
>> Yeah, it's probably hard to hard to
know. You got to be very in the details
of a specific, you know, spec or
implementation. Okay, cool. Well, I know
in at least from what I've seen at at
Coinbase and Bass, you guys have been
hiring a lot on the not only blockchain
engineering side, but like security like
blockchain onchain um security
engineering side of things. um how have
you identified who the good security
researchers, security experts are in
that onchain security field?
>> So for onchain security uh I have I have
a I have a team now and uh uh so when we
started building out that team it was
kind of harder uh but now we have a team
so and a good team so they help me find
other good people. Um so we have uh an
interview process that goes through
various things. So we we do like a risk
analysis round. We would give you
instances of uh uh use of onchain
products or protocols at Coinbase uh
like us trying to integrate with
something or us trying to build
something or use something and ask
people to kind of spot where the risks
might be. Um then we have an auditing
round which kind of is exactly what you
would expect it to be. We give a person
a piece of code and they have to find as
many bugs as possible. And and we have
uh we have a few other rounds too but
but I guess those two would be the most
important one. Uh uh yeah and then
there's also a presentation round where
uh you pick an exploit that that you
like and and talk about the exploit in
in detail and and also talk about how
somebody could prevent those sort of
exploits how uh users could be warned
and and uh how you could recover from it
or or uh prevent uh build some
preventative mechanisms. Uh so yeah, so
that's that's like the last part of the
interview process.
>> Interesting. Interesting. Well, I know
there's a lot of security researchers
that will watch this episode and they'll
be endlessly curious about the auditing
test. What can you say? Is it is it, you
know, 500 lines of code? Is it 5,000
lines of code? What is the is it
solidity? It is solidity. Uh it's not
that big. Uh and we have of course for
different levels we have uh uh different
auditing rounds four five and so you
know four is is kind of blockchain
security engineer five is senior six is
staff level uh and and the higher you go
the harder the test gets um and it's uh
I guess it's less about the lines of
code maybe it's more about uh the
complexity of the protocol that that you
need to look at um and uh at at level
six of course it's it's quite hard
>> interesting who's writing those level
six. I mean, are you custom writing
protocols with exploits in them?
>> Yes, pretty much.
>> Yeah. Wow,
>> that's super cool. And in terms of the
recruiting, you know, do you look at do
you look at public audit leaderboards
like Sherlock, like Code Arena
leaderboards? Do you look at, you know,
what audits people have done? How do you
how do you kind of vet candidates?
>> Definitely. Uh, so we do look at
leaderboards like your leaderboard and
other leaderboards. Uh we definitely do
that. It's it's not easy to get people
off of that board. Uh some people may be
anonymous, some people may or may not be
interested. So it's not it's not that
easy. But uh uh but a lot of people also
have their audit reports at least some
of their audit reports available uh
online. So they can share it with us and
that's also gives us some idea about the
kind of work that they have done in the
past. So it it we we have a good culture
in in the web free community. People go
through uh protocols go through audits
and and they don't mind sharing those on
the web uh so that you know other people
can take a look yeah this protocol has
gone through an audit and these findings
were there and they have been fixed. Uh
at the same time you kind of come to
know about some of the researchers who
participated in those audits. So
overall, I think this is kind of a good
culture in the in the web 3 community.
In web 2, I've not seen much of it, but
in web 3 there is. And uh it helps in so
many different ways.
>> Yeah, I I agree. I think it's awesome. I
think that culture is constantly under
attack in some ways where there's
certain things trying, you know, trying
to hide different things and whatnot and
different uh, you know, smart contracts
on maybe Salana are less often open
source or or verified. So yeah, it is
great that the space has come up that
way. And in terms of I guess last
question on that on that recruiting
topic, is the Coinbase and base security
team uh you know based in a certain area
like the Bay Area? Is it completely
remote? Is it uh you know certain time
zones?
>> So Coinbase is a fully remote company.
Anybody can work from anywhere. Um, and
most of my team, I think I'm the only
one in the Bay Area. Uh, I have one
person in San Diego. I think almost
everybody else is on the East Coast,
either in New York or New Jersey or
Virginia. Um, some people are in Canada.
And uh, earlier this year, we have also
started hiring people outside of the US.
Um so we opened the position in uh
London I think in Ireland uh and also in
Singapore and we did find somebody in
Singapore. So now who so he's in a very
different time zone right? Uh but he's
part of the team now.
>> Yeah. Nice. Nice. He's got to be about
12 hours difference from you or
something. You know one of the one of
the tougher ones I guess shifting gears
to bass. You guys have done some really
interesting security things uh with
bass. uh one of them being purchasing
onchain monitoring for every protocol
that builds on base. How does that work?
What was the idea, you know, behind
that? I think you're the maybe the only
chain that has taken that kind of step
on the security side. So, what can you
say about that?
>> Yeah, sure. So monitoring
we feel that uh it's something that
every onchain protocol should set up. Um
sometimes protocols
don't know how to set it up or don't
have the time for it or they may be
prioritizing other things and we wanted
to just make it very easy. uh we
partnered with hexagate and we kind of
provide a basic level of monitoring for
protocols for free um if you're building
on base if if they set it up so it's
actually pretty easy to set it up at
least a basic level of monitoring of
course if you want to customize right
your own monitoring heristics it takes
more time um but at at least a basic one
you can set up u so if your contract is
in under some attack uh and you have you
get the alerts in at the right time. It
helps a lot. U it could it could mean
that uh uh you may not be able to like
completely
avoid the exploit or like completely
save an entirety of the of the funds,
but you might be able to save a good
chunk of it. Uh and it could mean like
saving millions of dollars for your
users and uh and and to show that also
for the protocol, right? they would be
able to show that yes they have they
have uh they they're able to handle
these exploits in the right way. So yeah
so that was kind of the motivation
behind it. Uh during an incident every
minute every second matters uh and if
you have this right monitoring the right
alerting setup uh uh ideally everyone
should have a incident response plan um
and it's it's good to spend some time
thinking about it. So the program has
been running for I think about an year
uh and several protocols have have
onboarded um through this program. Uh
>> that's awesome. You know what can you
say about BAS's focus on monitoring?
Have you done some custom kind of
monitoring setups or what does that look
like?
>> Right. So uh for the base chain itself
we have uh a comprehensive suite of
monitors uh especially on the faultproof
part. The faultproof part is pretty
complicated. uh and we have set up uh
various kinds of monitors for it.
There's also we even open source those
monitors by the way and have have uh
some some blog posts about it too. Um
and then everything that we build uh on
chain it could be it could be our wallet
infrastructure uh smart wallets uh
identity base names or or things like
verified pools and other other
protocols. All of that uh is monitored.
Um and uh in in in almost all cases
during the audit process itself, we
would identify
how should we monitor this protocol. Uh
so we would come up with a set of
monitoring heristics and then we have
teams at Coinbase um who would help us
implement those monitors and they
already have an incident response plan
in place. Uh so there's all of the
alerts that are generated uh through
these monitors. is they kind of u going
to the same uh uh workflow that that
exists for for monitoring alerts and and
and responding to to those alerts. Yeah,
I was looking around and it looked like
you guys have spent a lot of time on
monitoring. Maybe even you know a few
years ago I think I saw a repo called
pessimism where you kind of open sourced
a monitoring system. Is there is there
more? I think that one's deprecated now.
Is there another one coming out soon
that you'll be releasing?
So pessimism was supposed to be the the
name kind of uh was a funny take on uh
optimism. Uh the monitoring worked for
OP stack. Uh so it was uh not just for
base but any anybody that uh or any
chain that that builds on OP stack. It
was for all of them. And back then I
think uh the monitoring solutions that
existed we thought were uh not quite
enough for what we wanted to monitor. Uh
so we kind of built our own monitoring
tool but then uh we started working with
uh Hexagade and kind of realized that
most of what we need can be um can come
from there. Uh and uh uh we kind of also
worked together to build uh new features
that were needed in in in uh monitoring
the things that we cared about. Uh and
at some point we realized that pessimism
is maybe not needed anymore. Uh and
everything that we kind of wanted
pessimism to be we could get it from
from hexagate. Uh um so we retired
pessimism after that.
>> Okay, that's cool. And you mentioned you
know opt stack fault proofs. One of the
things that I found really interesting
was optimism alone put a lot of effort
and you know money and time into doing
audits and securing the OP stack and all
of that and then you guys from what it
looked like almost took like a clean
slate approach and just started over and
said you know we're going to not assume
anything we're going to do our own
auditing and security processes on the
OP stack. How did you think about that?
I mean, it seems like you took a really
in-depth approach to making sure the OP
stack was secure for you.
>> Base bridge in particular, right? Uh it
holds a lot of money and there is
basically no room for error there.
Absolutely zero room for error. So, we
want to anytime we make changes to how
the bridge operates, how withdrawals
work, we want to be absolutely sure. So,
it's good that other parties do their
due diligence. you have to do our due
diligence as well. Um so internally we
have team members who understand that
system really well. They would do their
reviews. Uh and and then we also go to
external parties to get their reviews as
well. And and we we then bake in time to
fix everything. Everything that is found
internally, everything that is found
externally, all of that needs to needs
to be fixed in time before any of our
contracts are upgraded. Um and this is
our standard process.
Anything that we want to launch on
chain, we have to be absolutely sure. So
internal audits, external audits,
sometimes multiple rounds of both
internal and external audits. And and
there's of course the bug bounty
program, the the big bug bounty program
that that we have that also helps people
to report things that that they may
find.
>> How do you know? So you said you do
multiple rounds of audits. How do you
know when you're done doing audits? How
do you know when enough is enough?
>> Yeah. Uh so one, you know,
one signal is is when you basically just
don't find anything anymore. Uh at some
point you would only find lows
andformationals and and then you kind of
know this is where we stop. And in most
cases, our target is that uh uh we
should be able to do an internal audit
so well so good that externally
no high no critical is found. that means
we are internally able to audit
everything very well. Um that's our
standard and uh yeah I would say uh that
that setting that kind of standard helps
us basically catch almost everything
internally itself and and then uh if if
we miss something uh then then
externally it is caught. So hopefully
hopefully this this this combination of
uh us who is already independent of the
product team that's actually building
these products um
>> already independent of them and then you
know external folks who are also uh
independent. So there there is at least
two sets of independent eyes looking at
uh every protocol um and like I said
before we we might go through several
rounds of this. Um so yeah at the end uh
we are we are confident that uh there
should should not be anything serious
here.
>> Yeah. Yeah. Makes a lot of sense.
There's there's a saying that some
people in the web 3 security space have
been uh posting on Twitter like your
your last audit should feel like it was
a waste of money.
>> Yeah.
>> Basically it sounds like you subscribe
to that kind of approach.
>> Definitely. Yeah. That's that's a good
way to think about it. Uh there there
shouldn't be any any significant finding
in in your last audit. uh uh and of
course the person the people who audited
uh the company who audited should be
should be good right uh and and they
shouldn't be able to find anything
interesting. So, in terms of your
internal security team, you've been
building it out. You have these
different, you know, levels and and uh
and ways of hiring. Um, I think there
was an announcement maybe this summer
that some of the teams that build on
base can get access to your internal
auditing team and get like a maybe it
was a security review from that team.
How does that process or program work?
>> It's a small program. we can uh we can
review uh or we like we review a small
very small number of protocols that uh
um that are building on base or or have
built on base. Uh
so we people can apply uh we we are
accepting applications uh all the time.
Uh but really we can only review a small
number of protocols at any given time. A
very small number uh and this is not
supposed to be a replacement for a
proper audit.
um we we do it on a best effort basis
and and you know we can only dedicate
some amount of time to these reviews. Um
so we do the best we can and uh we make
it very clear that you know you should
still get a proper audit um uh from from
companies like you or from other
companies but yeah it's still a small
program uh and and we have reviewed a
small number of protocols so far.
>> Got it. Got it. And what's the criteria
if if a protocol wanted to apply? Is it
protocols that that you assess will have
the greatest impact on base or is it
some other criteria?
>> Right. So the selection of protocols is
actually outside of my team scope. Um we
have we have other teams uh uh the base
the base ecosystem team and the base
there's other people working on base uh
and who have um who kind of spend more
time on this and who have closer uh
relationships and and and knowledge of
of what's going on in the ecosystem more
broadly uh and and they select the
protocols kind of for us uh and and then
we review them. Yeah. So they they have
their own criteria and uh of course
impact is one but there could be other
criterias uh too u and and our job is to
yeah do a good review.
>> Yeah makes sense. I think I was reading
something that your team you know uses
fuzzing and some other um you know types
of testing. What can you say about like
how your your internal security team
prioritizes different types of security
I guess like fuzzing or manual review?
Uh so we do use some tools um and and uh
I mean some of those tools are very
wellnown but most of the value comes
from manual auditing like I don't think
uh there is anything that replaces
actual humans looking at the code and
finding problems. Um the tools kind of
can help a little bit. Um most of these
tools have false positives too and and
of course everyone's looking at AI these
days and the hope is that maybe AI tools
can can get to a point where they can
also catch some criticals and highs
themselves. I'm not sure we are at that
stage yet. Um so uh internally at least
as of today uh most of what we do is is
is
very manual. Um yeah there is there is
we use tools but uh um to to a certain
extent uh and and most of the critical
findings still come from u manual
reviews.
>> Yeah. Yeah. Makes sense. Um you
mentioned AI AI tools. What are your
thoughts on the AI auditing tools? Do
you think they can be effective? You
know do you think they replace human
auditors at some point in the future?
>> AI is moving very fast. Uh uh everyone's
kind of coming out with their own AI
agent to detect smart contract
vulnerabilities. Our experience so far
has been kind of mixed so far and it
could change in the next few months, few
quarters. Um but so far it has been kind
of mixed. Uh still the false positive
problem is there. They're also not very
deterministic. So, you know, if you run
them again, you find something else,
different descriptions, different
severity levels, like uh
>> and uh once in a while they'll be able
to catch something good. Uh but uh on a
on a general day-to-day basis,
especially when you give AI
a new type of protocol, uh it wouldn't
do very well. Uh yeah, that's that's
been our experience. But uh we are
excited about AI and like things are
moving very fast. Uh so we want to
we want to look at the different tools
that that various companies are building
like you're you you're also building a
tool. Uh so we want to look at those
tools and and see if they can be
adopted. Uh we would want to test them
out internally first. Uh see if if they
work well for for our needs. uh and if
they are up to the standard where uh you
know false positive rate is low and and
recall is good uh and then we may also
consider offering it to to people
outside of Coinbase outside of base.
>> Got it. Yeah, makes sense. Makes sense.
Um and where do you see do you have an
opinion on where you think AI auditing
goes? Does it stop you know somewhere
and kind of its effectiveness
falls off? Um or do you think it just
keeps getting better? How do you think
about it?
>> I think there is definitely room room to
get better. Uh a lot of room uh uh so I
think at least for the I'm not I'm not
an AI expert by any means. Uh so at
least but but I can I can see that for
the next one or two years at least it it
it'll just keep getting better and
better and better. Um but at some point
it uh uh at some point the the returns
would would start getting more smaller
but but at least for now there is there
is a lot of room to to get better. So I
I also feel that maybe there is just not
enough solidity code out there in the
world as compared to say the amount of
code written in other languages. Uh
>> yeah, and that could be a reason why on
on on like smart contract languages like
Celebrity, uh AI tools generally don't
do that well. Yeah, makes sense. Makes
sense. And I guess in terms of AI
tooling, I mean, I've seen some of Brian
Armstrong's tweets about like, hey, our
company, I think he said 40% of the code
we write at Coinbase is AI generated or
used um someone used AI and he's trying
to push it to 50%. Is this also true on
the security team? You know, do you use
AI tools to write code? How do you how
do you kind of think about it? So AI is
definitely uh has been a big push um at
the company. Um so we want to adopt AI
into as many work streams as possible.
Uh so writing code is is one, reviewing
code is another one. Then uh use of AI
for threat modeling, use of AI for risk
assessment, use of AI for smart
contract, vulnerability detection. So we
want to adopt AI as much as possible uh
wherever possible. And uh in some cases
we have like writing code right uh we
have already made quite a bit of
progress uh and in some cases uh we are
still in in the exploratory phase um say
for smart contract uh vulnerability
detection we're still in a phase where
we are evaluating tools um but we
haven't really uh come across a tool
that's like made us very happy. So yeah,
but but in any case uh as as Brian says
like uh uh we we want to adopt AI and
make our processes efficient uh across
the company uh in any work stream
possible. Cool. Uh let me see. So you
were also talking earlier about you know
doing multiple rounds of security
reviews. I know in at some points you've
done audit contests um for for code
bases uh with base and and maybe some
others as well. Um when do you how do
you think about audit contests and and
when you use them and when you don't?
>> We have done some audit contests. I
don't think we have done that many. Uh
so my my take would be that uh certainly
review everything internally first. So
you would ideally as as a development
team or internal security team you want
to catch at least all the small things
um up front so that uh your external
auditors can focus on the the bigger
things right uh u so do as good as as
good of a job internally first then
externally uh maybe the first round of
auditing should be private um so you
know a small number of researchers two
or three or four take a look at their
their contract cracks and you know find
problems, you you you can fix them and
and then maybe a second round of
auditing or in some cases a third round
of auditing could be a contest, an open
public contest. Um where uh hopefully a
larger number of researchers would try
to attack your protocol and find
problems and fix it. Um yeah, that's
that's how I would uh kind of approach
it.
>> Yeah, makes sense. Makes sense. So for
critical kind of code where you want to
do two or three different rounds of
audits that can be part of the closer to
the end of the process.
>> Yeah.
>> Um and you also where I saw something
that I believe it was base um completed
some like war gaming simulations.
What can you say about that and how that
kind of fits into the the security
mindset overall? So we uh we do on a
regular basis tabletop exercises
uh to to simulate uh
some b some bad scenarios like what if
this happens on base how would people
react? Uh so we invite all the uh all
the relevant parties. It could be it
could be people from security,
engineering, legal compliance. So we
invite everybody uh and we also put like
so certain people on alert that that
look at this time this tabletop exercise
is going to happen. So uh be available
and we might need you for decision
making right uh at that point. Uh so we
do this on a regular basis and we kind
of consider some like really bad cases
uh really bad situations and uh uh kind
of try to push ourselves to the limit
like what what if this really bad thing
happens on base how how would we uh how
would we react to it what kind of
measures we'll take to recover from it.
Uh so we do that exercise and in every
exercise we we would uh learn things
like we would identify gaps and then go
back and try to address those gaps and
in one case uh we also did a tabletop
with an external party uh so seal uh
they helped us run the tabletop uh and I
think maybe that's what you were
referring to earlier uh and it was both
uh it was both uh base and optimism who
participated in that exercise. Um so
they I think this was a while ago so I
don't remember all the details u but I
think they set up like a test chain and
kind of tried to exploit that test chain
and we were supposed to assume that uh
that test chain is like our chain um so
we could you know we had certain things
that we could do it was also a test for
our monitoring system. So so we kind of
pointed our monitors through that test
chain and uh uh also got a chance to
test if if our monitors actually would
fire off if something bad happens.
>> Yeah. Hm. Interesting. Interesting. Do
you think this is something that you
know every chain should do? Do you think
protocols built on top of chain should
be doing it? What was your experience?
>> I mean ideally everyone should do uh
this kind of an exercise. Um so everyone
should have an incident response plan
really. Uh and uh this sort of an
exercise that the more the more time to
you put into it that the better it will
go. So it may not always be easy to find
time to organize it. Uh but it it
actually has a lot of value u and as
your protocol or like your chain goes
grows bigger and bigger uh it becomes a
bigger target for attacks, right? Uh so
you should actively very actively think
about if you were attacked. Like of
course you go through all the audits and
reviews and whatnot, right? uh but it
might still be possible that that that
you miss something. Uh so you should be
prepared for the for the absolute worst
cases. It's it's it might it might be
odd to think about them um sometimes but
uh it's good to think about them.
>> Yeah. You don't want to think about it
for the first time when it's when it's
happening. Yeah. Okay. Interesting. And
I guess one of the other measures, you
know, audits and whatnot can help
prevent that. Um, another one is bug
bounties. You you guys run, I believe,
two different external bug bounty
programs. I think I saw you have an
internal like hotline for bug bounties.
Um, how do you think about bug bounty
programs and and their value?
>> Yeah. Know bug bounties are are great.
Uh, we have two exactly what you said.
We have two uh for web two we have
hacker one and for web three we have a
different one. And I I mean we we
originally had just one the one through
hacker one but but we kind of realized
that uh we are not getting very good uh
web 3 related submission. So we set up a
separate one for web 3 and uh it's it's
it's a part of a wider effort to engage
the community um to to get people to to
spend some time trying to poke holes in
our systems in our contracts and if they
find something then uh um they can
report it to us they'll be rewarded for
it uh and it it gives us an opportunity
to fix fix it in in time before it
affects anybody else. Um so I I I think
boundaries are are are very important
like uh uh everyone it's also something
that is easy to set up. Um uh similar to
monitoring at least a basic level of
monitoring is easy to set up. So in a
similar way I think a basic level of bug
bounties are also easy to set up and and
maybe initially again as your protocol
grows may grows maybe initially the
rewards may be low uh but as you're
growing you can up the rewards to to
maybe get more attention on the on the
platform and and hopefully hopefully
some some uh white hard attacker may
able to catch things first before before
somebody else does and then you have an
opportunity to fix it.
>> Yeah, I agree. I think I think bug
bounty programs are great. Have you seen
any change in bug bounty submissions
with AI? You know, we've we've heard
from some areas that the number of
submissions has increased. I don't know,
have you seen that on your internal
hotline or or you know, experienced that
in any way?
>> Yeah. Uh so now people can uh use AI to
uh submit reports and uh these reports
they they may look very elaborate, very
detailed but yeah when you take a look
at it uh take a closer look you realize
kind of that it may be AI generated and
it leads to a lot of of course there's
extra work now for the triagers
uh and and sometimes a report may look
very very legitimate and then you spend
a lot of time on it only to find that
that makes some invalid assumption or
the P is is uh uh bad for some reason.
So there is there is more work now with
uh with the use of AI. So we have to
again kind of use AI on the other side
>> to to be able to like classify these
submissions and uh and and and maybe
maybe have some agent that that does an
initial round of triaging, right? Uh so
those things also need to be looked at
but but yeah with because of AI we are
seeing uh maybe more um invalid but
legitimate looking submissions than we
did before. Yeah. Yeah. It's a a tricky
problem and I I agree. I think using AI
to combat it in some way is part of the
solution. I guess in terms of you know
your career path and and the role that
you have now. Um you know a lot of
security researchers who watch this
might be interested in making it to a
role like yours one day you know head of
security at a at a large blockchain.
What advice do you have for someone
who's maybe younger starting their
career um to to get to a role like yours
someday?
>> I don't think there is like very a very
well- definfined path. uh I have I have
met with a number of security
professionals in the past like and and
everyone has their own had their own
journey of of getting where they were
where they are. So I don't think there
is like one very well- definfined path.
My my own journey has been uh kind of of
a different kind right uh starting from
cryptography then slowly getting into
blockchains and slowly getting into
blockchain security. So yeah, I mean it
was a longer path and uh uh I I learned
a lot of different things along the way.
It also gives me a broader perspective
uh of things. So when I look at a
blockchain, I I I kind of I guess oh uh
see more things uh uh may be able to
like notice more attack surfaces or more
types of risks uh with the blockchain
than than just the smart contract
portion of it, right? Uh yeah. So for
people who are new to this field, well
uh if security is something that
interests you, then then I think
starting from uh uh starting from maybe
uh auditing smart contracts is is could
be a good uh could be a good starting
point, right? So that gives you that
makes you familiar with at least the the
execution environment of of these
blockchains. But along the way, I think
I guess try to learn about uh the other
aspects of a of a blockchain, the
consensus parts of a blockchain, um
block building, uh and and there's
there's so much more to it, right? Uh of
course, of protocols, even many of the
off-chain pieces like how do you manage
keys is also pretty important. I I guess
kind of building a more holistic
approach um and and and and learning
about these various components uh could
get you into uh uh a good spot and and
uh yeah maybe maybe help you uh with
with your role if you're interested in
like a security role then then yeah uh
the sort of a more holistic
understanding of of of blockchains and I
mean we we kind of mostly focus on the
onchain pieces but the offchain pieces
are also So uh very important for
security, right? Uh so yeah, building
this kind of holistic understanding over
time would would help a lot.
>> Got it. Got it. Yeah. It's not just
about the solidity smart contracts.
There's a lot of other vectors you have
to be proficient at. In terms of you
know web 3 security, as we just spoke
about a lot of different aspects of it.
Do you feel that you have any
particularly
controversial opinions on a web 3
security topic that you'd like to share
>> contro? I don't know if it is
controversial but uh uh
uh so I I I see that so so there is of
course different types of like ways of
approaching security. So there's there's
there's a certain set of folks who would
not worry about security so much. Uh and
if they uh they maybe focus more on
development, not so much on security,
they don't have anything dedicated, they
don't have anybody dedicated to security
on their team. It happens especially in
early stages. Um and then there's
there's maybe a set of folks who kind of
really focus only on the smart contract
pieces. Um and if they get an audit of
the smart contract, we're like, "Yeah,
good. you're all all good to go. Um, but
like I was saying before, this is this
gives you protection against one type of
attack. Um, and uh I think in the last
one or two years, you've seen many
attacks where something off the chain
was compromised. Um, one of your keys
was stolen um somehow or you were made
to sign a transaction that you weren't
supposed to sign. Uh so those thing
those those offchain pieces are equally
important very important uh especially
if you have like these privileged roles
in your contracts then then protecting
keys for those privileged roles is very
important. Um and of course like what
you're signing is is critically
important. So all these pieces of your
infrastructure
are very critical and they need to be
looked at as well. uh and uh and and and
similar to how so it's it's good if
somebody's paying attention to their
contract, they should also pay attention
to these off-chain pieces as well. Uh uh
again, as as you grow and and maybe your
TVL hits in hundreds of millions or like
billions or something, uh then uh it
might be it might be easier to attack
one of your off-chain pieces than your
onchain pieces. Um and and people would
always go for the weakest parts in your
security posture. Again, like I said,
it's not it's not nothing controversial.
I'm not saying anything new here. U but
uh but yeah, it is it is very important
to pay attention to all these other
aspect even if you are a fully onchain
protocol and and you you may be doing
the the most interesting things
interesting things on the chain. U all
of these offchain pieces are also
important and and they need to be looked
at as well.
>> Yeah. Yeah, it's a great point. We've
definitely seen the key compromises, the
front-end kind of compromises um and
that sort of thing and those get way
less airtime than the smart contract,
you know, contests and vulnerabilities
and things that people hear about all
the time. So, yeah, it makes a lot of
sense. Well, I know we're we're running
up on time here. We'd love to get a
couple more in. What are what are kind
of your favorite um security events
throughout the year? Do you go to some
of the more, you know, DeFi, Ethereum
aligned ones? You go to cryptography
conferences? Yeah. What is it like for
you and your team?
>> Right. Uh uh so we try to attend some
conferences during the year. Uh
I uh I I I attended Dev Devcon last year
and uh I attended token 2049 this year.
It's hard to attend maybe more than one
or two conferences every year. If
something is local uh then it's somewhat
easier. Um so one one conference that is
more I guess more academically inclined
uh is the science of blockchain
conference. It used to be called
Stanford blockchains conference. I think
it's called science of blockchain
conference now. Um uh so whenever it's
in the Bay Area I I definitely uh try to
attend it. Uh and and then uh yeah and
and there is like you know ETH each
Denver ETC those conferences as well. So
e either myself or some other person on
the team would would go to these
conferences and uh um try to try to
connect with people and and and try to
uh learn from there. So that's I guess
that's that's how we uh approach
conferences and and every once in a
while we we would also have a speaking
slot. So we have one speaking slot at at
DSS uh coming up in in November um where
a person from my team is going to talk
about uh uh bridging between two
different uh execution environments like
bridging between say uh an Ethereum
based one and a Solana based one. What
does it entail? So yeah, but but
conference participation is great like
yeah, a lot of learning and a lot of
connection opportunities there.
>> Awesome. Awesome. Yeah, I I'm very
excited for DSS this year as well.
Should be should be a good one. I guess
in terms of, you know, last question in
terms of what's going on with with base
or or Coinbase, what's the most, you
know, what are kind of the most exciting
things on the road map or what areas are
you most excited about in the in the
future here? So, Coinbase uh uh is is
bringing more and more things on the
chain. Uh you have you you may have
heard about our acquisitions this year.
Uh we acquired uh Spindle, we acquired
Ironfish that that had its own private
blockchain. Uh and we recently acquired
Echo that's for capital formation on
chain.
>> Uh so we are we are trying to move as
many things as possible on the chain. Um
so that means there is more to secure
right uh and in addition to that you're
also bringing uh uh we are also bringing
more things to our uh more things to our
exchange app uh our retail app right uh
uh right now it it uh primarily deals
with crypto tokens right uh uh but we
want to bring traditional equities and
everything uh on the on the exchange as
well um and and and some of this would
also might also uh be tokenized and
might may have uh a representation on
chain. So again that's that's another
thing for us to think about and secure.
So there would be there is this there
just so much work and activity uh in the
at the company right now to try to bring
as much of the traditional economy on
the chain. Uh we're very excited about
it and uh of course it also means
there's a lot of work for us to do to to
secure it.
>> Awesome. Awesome. Well, yeah, I love I
love to see that. I know Coinbase has
been doing that for a long time. I guess
Bass was one of the big kind of initial
forays. Um and yeah, I think a lot of
the exciting and and innovative things
are happening on chain. That's where
Sherlock is spending a lot of time, all
of its time really, uh as well. So love
to hear that you know more and more
things are coming on chain and and will
need need securing essentially.
>> Awesome.
>> Cool. Well, thanks so much for joining.
Um really great uh really great hearing
all the different aspects of what's
going on at at Coinbase and Bass. Um and
yeah, thanks for coming on today.
Shashank,
>> thank you so much. Yeah, thank you for
having me.
Coinbase’s internal security process is designed so that it’s very rare for an external audit to reveal any high or critical issues. Shashank Agrawal, Head of Security at Base, breaks down their multi-round validation workflow, how it protects more than $7B in Base TVL, and why off-chain infrastructure receives the same scrutiny as smart contracts. ABOUT SHASHANK AGRAWAL Shashank leads protocol security for on-chain development at Coinbase and serves as the head of security for Base. He holds a PhD in cryptography from the University of Illinois Urbana-Champaign, previously conducted cryptography research at Visa Research and Western Digital, and has published extensively on multiparty computation, zero-knowledge proofs, and blockchain security. CHAPTERS 00:00 Intro — Shashank Agrawal, Head of Security at Base 00:17 Why Base upgrades carefully 00:34 Coinbase’s open-source MPC library 00:52 Can AI catch real smart contract bugs? 01:03 Off-chain security risks explained 01:23 Shashank’s role across Base + Coinbase 01:42 Early programming in India 02:26 Learning C, OOP, and CS fundamentals 03:19 University programming + early AI exposure 04:26 Moving to the U.S. for cryptography research 04:55 PhD work: MPC, ZK, encryption, crypto theory 05:56 Why theory led him to applied cryptography 06:50 Leaving academia for real-world crypto 07:17 Visa’s crypto research team 08:14 Publishing MPC & PQC research at Visa 09:37 Getting deeper into blockchain research 10:25 Western Digital — proof-of-space blockchains 11:53 Moving from WD to Coinbase 12:22 Why Coinbase was the right next step 12:51 Early Base security work 13:47 Securing all Coinbase on-chain systems 14:31 Global collaboration across security teams 15:15 Staying current with cryptography research 15:54 Why MPC matters for Coinbase key management 16:28 Building Coinbase’s in-house MPC library 17:44 Open-sourcing MPC for community review 18:09 Why you should never “roll your own crypto” 18:42 Coinbase’s crypto spec + audit workflow 20:22 External professors reviewing Coinbase crypto 20:52 Why Coinbase open-sources its libraries 21:14 On cryptographic backdoors & trust 22:14 Hiring blockchain security engineers at Coinbase 23:08 Coinbase’s audit test + interview process 24:58 Using past audits to spot top candidates 25:44 Why Web3’s open audit culture works 26:42 Coinbase’s global remote security team 27:24 Base’s free on-chain monitoring program 28:53 How monitoring prevents multi-million exploits 29:59 What Base monitors (chain, wallets, identity) 31:14 Retiring Pessimism → adopting Hexagate 32:37 Re-auditing OP Stack from scratch 34:15 Knowing when audits are “enough” 35:44 Internal audits must catch all highs 36:33 External audits should feel like overkill 36:58 Base’s internal reviews for ecosystem projects 38:05 Choosing which protocols get audits 39:11 Tools vs manual audits — what finds bugs 40:27 Why AI auditing still isn’t ready 41:27 Evaluating AI tools (precision & recall) 42:11 Will AI replace auditors? 43:08 How Coinbase uses AI internally 44:30 When Base uses audit contests 46:14 Audit contests in the audit pipeline 46:43 Simulating chain attacks (war-games) 47:43 Why all chains need attack simulations 50:17 Coinbase’s Web2 + Web3 bug bounties 51:15 AI causing bad bounty submissions 53:15 Career advice for Web3 security engineers 54:43 Why broad blockchain knowledge matters 56:31 Biggest risk: off-chain compromises 58:59 Frontend + key theft risks 59:41 Conferences Shashank attends 01:00:44 Bridging Ethereum ↔ Solana securely 01:01:38 Coinbase’s roadmap: tokenization & new chains 01:02:49 Bringing global finance on-chain securely 01:03:39 Closing thoughts RESOURCES MENTIONED Coinbase MPC Library (open source): https://github.com/coinbase (verify actual link) Hexagate Monitoring Platform Seal Security (tabletop exercise partner) Science of Blockchain Conference (formerly Stanford Blockchain Conference) SUBSCRIBE for more conversations with security leaders at top Web3 companies on audit methodologies, hiring frameworks, and implementation strategies. CONNECT WITH SHASHANK LinkedIn: https://www.linkedin.com/in/shashank-agrawal ABOUT WEB3 SECURITY PODCAST Exploring the discipline of Web3 security through conversations with those leading security at major crypto and blockchain companies. Features discussions on security philosophies, strategies, vendor evaluation, and lessons learned.