►
Description
In this AMA, Sam (Hexonaut) and Kris (Krzkaczor) discuss the Maker Wormhole that is being developed, and scheduled for full release in Q2 of 2022.
Wormhole is a product developed by the Protocol Engineering Core Unit of MakerDAO, created to port DAI to any blockchain, Layer 1 or 2.
Contact Info:
Protocol Engineering:
Chat - https://discord.gg/DB9PetTw
Forum - https://forum.makerdao.com/c/core-units/protocol-engineering/38
Sam (Hexonaut):
Chat - hexonaut#6741
Forum - @hexonaut
Twitter - @hexonaut
Kris (Krzkaczor):
Chat - krzkaczor#6240
Forum - @krzkaczor
Twitter - @krzKaczor
Jerry (JerryAG)
Chat - Jery.G#6157
Forum - @JerryAG
Twitter - @JellyProducer
A
Right,
hello,
everybody
and
welcome
to
our
12th
ama.
Today
we
are
joined
by
chris
and
sam
from
protocol
engineering
to
talk
about
maker
wormhole.
A
lot
of
people
here
joined
sure
there'll
be
a
lot
of
good
questions.
So
let's
just
go
ahead
and
jump
right
into
it.
I
know
chris,
you
want
to
go
ahead
and
give
some
background,
so
I
will
pass
it
over
to
you.
B
B
Okay,
great
so,
first
of
all,
like
some
wrote
down
all
the
details
about
maker
wormhole
in
in
the
in
the
forum
governance
forum,
so
you
can
read
that,
but
actually,
like
some
details
of
this
design
are
outdated.
Now
and
let
me
let
me
go
through
the
current
version
and
yeah.
So,
first
of
all,
the
problem
that
we're
gonna
that
we
want
to
solve
with
with
die
wormhole
is
teleporting
die
between
different
domains.
B
So
by
domain
I
mean
basically
a
layer,
two
or
even
a
side
chain
that
is
somehow
somehow
connected
to
the
ethereum
magnet.
It
could
be
even
there
other
different
layer.
One
like
this.
The
system
is
quite
unopinionated,
but
I
guess
that
our
governance
will
be
opinionated,
so
I'm
using
domain
and
layer,
two
here
kind
of
interchangeable.
B
So
so
we
want
to.
We
have
die
on
one
domain
like
optimism
and
we
want
to
teleport
it
to
another
domain
like
rpg,
and
so
you
know
this
is
needed
for
many
different
reasons,
but
also
like.
If
you
have
a
optimistic
relapse,
you
have
this
problem
of
slow
withdrawals
right
going
through
like
withdrawing
to
layer.
One
takes
seven
days.
B
So
if
you
would
do
it
like
naively,
which
is
like
withdrawal
to
layer,
one
your
die
first
and
then
deposit
on
different
domain,
it
would
take
like
seven
days,
but
also
this
mechanism
can
can
be
useful
just
to
avoid
moving
a
lot
of
die
through
layer,
one
even
between
like
zika
roll-ups,
which
don't
have
this
seven-day
delay
period
right.
So
this
is
more
or
less
the
context
of
what
we
want
to
do.
B
And
now
our
solution
mark
works
like
this
users,
let's
focus
first
on
a
more
generic
case,
which
is
a
layer
two
two
there
to
wormhole
so
on
layer,
one
layer,
two
a
which
is
in
this
case
optimus.
We
have
users
that
call
initiate
wormhole,
and
this
call
burns
dye
immediately
on
this
layer
too
and
and
issue,
and
it's
emitting
some
kind
of
event
and
this
event
is
being
watched
by
maker
oracle
oracles.
B
So
this
die
is
gonna,
be
minted
by
mcd
instance,
special
vault
on
mcd
instance,
on
on
this
particular
domain
like
arbitron
and
and
it
it's
collateralized
by
a
promise
of
future
die.
So
what
happens
under
the
hood
is
that
we
have
a
network
of
keepers
that
will
periodically
flash
the
the
dye
that
was
burned
on
on
originating
domain
and
move
this
dye
slowly
to
the
destination
domain.
B
B
B
When
you
know
our
ecosystem
is
down
or
it
doesn't
work,
so
the
slow
path
works
in
the
way
that,
when
initial
wormhole
calls
are
happening
to
out
on
the
originating
bridge,
we
emit
cross-chain
messages
messages
that
that
usually
are
not
are
never
finalized.
So
the
thing
about
crosstrain
messages
in
in
case
of
relapse
is
that
they
are
very
cheap.
Like
really
what
what
happens?
B
B
So
this,
this
operation
of
rebalancing,
dead
between
bridges
happens
once
per
day
or
once
per
some
period
of
time,
which
means
that
we
gather
all
the
smaller.
You
know
wormholes
created
by
users,
and
we
just
settled
that
at
once,
and
this
is
where
we
get
scaling
benefits
on
layer.
One
we're
just
gonna
have
one
transaction
per
day
or
even
per
few
days,
which
is
awesome
for
skating
from
skating
perspective.
B
Also
known
as
fast
withdrawal
and
then
it's
it's
quite
similar
case,
just
the
difference
is
that
you
don't
bridge
to
different
domain
but
to
layer,
one
and
frankly,
the
technical
solution
is
also
very
similar.
We
have
this
wormhole
router
that
takes
care
of
like
routing
the
requests
in
to
either
to
the
bridge
or
to
the
mcd
instance
on
layer,
one.
B
C
B
B
C
Yeah,
so
there's
two
kind
of
components:
to
that
I
mean
governance
can
really
choose
whatever
they
want.
I
mean
to
charge
a
fee,
so
there's
sort
of
like
the
do.
We
want
to
make
revenue
off
this
sort
of
question
and
I
think
that's
more
thrown
to
governance
and
we
can
like
kind
of
go
with
whatever
governance
wants
on
that
there's
sort
of
a
second
component
to
this,
which
is
due
to,
as
chris
said,
the
sort
of
fungible
bundling
of
all
the
transactions
into
one
block
of
settlement.
C
It
sort
of
introduces
a
denial
of
service
attack,
vector
and
sort
of
the
naive
case
where
we
don't
charge
a
fee,
so
we're
currently
sort
of
doing
r
d
on,
like
figuring
out
a
way
to
mitigate
this
likely.
We
will
need
to
charge
some
fee
to
sort
of
prevent
people
from
doing
this.
Denial
of
service
attack
and
just
sort
of
blocking
people
from
getting
die
on
the
target
domain.
C
D
B
B
C
Right
so
during
this
sort
of
fast
path,
withdrawal
and
it's
important-
there's
a
debt
ceiling
on
the
wormhole
debt
as
well
such
that
you
know.
If
there's
something
goes
wrong,
you
don't
want
to
like
just
blow
up
the
whole
system
right,
so
we
have,
we
do
have
a
debt
ceiling
there.
So
what
can
happen
is
let's
say
somebody
I
don't
know
they
want
to
take
the
slow
path
or
whatever
to
exit
and
get
their
die
out.
C
C
The
debt
ceiling
is
10
million
on
arbitrarium.
There's
two
people
wanting
to
go
from
optimism
to
arbitrarium.
They
both
meant,
I
don't
know
three
million
each
and
so
there's
like
six
million
going
through,
and
so
those
two
people
can
sort
of
do
a
fast
withdrawal.
There's
ample
debt
ceiling.
They
can
sort
of
get
their
diet
right
away.
That's
fine!
C
Now,
let's
say
somebody
wants
to
withdraw,
say
four
million
and
for
whatever
reason,
they've
they've
taken
the
slow
path,
so
they're
waiting,
seven
days
that
their
die
that
they
have
burned
has
already
been
transferred
to
the
target
bridge
in
that
case,
so
they
should,
in
theory
be
able
to
be
served
immediately.
But
what
can
happen
is
let's
say
somebody
comes
in
with
a
10
million
dollar
transfer
request
between
optimism
to
arbitrarium,
and
they
execute
the
fast
withdrawal
right
away
before
this
user
can
execute
their
slow
path
withdrawal.
C
C
A
B
E
C
Peyton,
both
okay,
so
for
the
first
one
yeah
part
of
what
we're
evaluating
is
some
sort
of
a
way
to
potentially
have
a
fifo
cue
of
sort
of
giving
priority
from
who
has
initiated
the
transaction.
We're
still
investigating
that,
like
that,
may
be
useful
for
preventing
denial
of
service
and
so
we'll
see
and
for
the
auctions
thing.
So
this
is
a
priority
queue.
C
I
guess
this
is
for
sort
of
in
the
case
where
there's
a
big
market
crash
and
die
liquidity
runs
out
on
some
l2
there's
potential
to
use
wormhole
to
get
there
quickly.
Yeah,
I
think
that's
a
great
use
case.
For
you
know,
one
l2
has
a
lack
of
liquidity
and
the
other
one
has
a
bunch
of
liquidity.
Yeah.
You
can
use
the
fast
the
worth
the
the
wormhole
rather
to
get
die
liquidity
to
where
it's
needed
quickly.
E
E
That
auction
could
clear,
before
your
capital
made
it
across
the
bridge,
even
in
the
like
multiple
blocks
that
it
may
take
to
do
that,
and
so
we
we
may
need
to
think
a
little
harder
on
auctions.
But
that's
actually,
I
think,
the
just
more
broadly.
I
think
the
more
exciting
thing
about
this
is
to
think
about
what
what
the
ecosystem
even
could
build
on
top
of
this
once
it's
there
right,
because
we're
talking
about
just
moving
dye
from
chain
to
chain.
E
But
if
you
have
the
right
kind
of
liquidity
pools
right,
you
can
move
more
than
just
die
from
chain
to
chain
like
you
can
basically
swap
your
f
and
to
die
and
then
move
the
die
across
the
wormhole
bridge.
And
then
on
the
other
side,
you
basically
throw
your
die
into
an
f
pool
and
get
your
f
back.
So
now
we
can.
We
can
use
this
as
like
a
die
as
a
sort
of
conduit
to
move
any
asset
across
chain.
E
B
Yeah,
I
also
thought
about
the
site
given
given
a
really
good
liquidity
on
the
on
the
die
pairs
like
we
could
think
about
it.
As
a
you
know,
generic
breach
as
long
as
you're
reading
to
take
some.
You
know
slippage
on
amn's
in
and
out
right,
it's
kind
of
similar
to
what
hop
does,
but
with
dye
instead
of
like
age
tokens.
B
There
was
this
question
like
chris.
I
wanted
to
come
back
to
to
the
to
your
comment
about
auctions.
Right,
like
regarding
auctions,
like
I
think
that
you
know
you
still
can
use
flashlights
whatever,
like
we
deploy
as
a
part
of
mcd
on
layer
2,
we
deployed
the
flashlight
module
because
someone
asked
this
question
on
chat
and
you
could
still
use,
like
you
know,
flashlights
on,
while,
while
finalizing
auctions
but
you're
right
that
there
is
no
like
cross
chain
composibility
one
in
one
block,
but
basically
the
risk
parameters.
B
E
Yep,
it's
we'll
have
to
see
how
it
plays
out
and
what
we
run
into,
but
yeah
the
distinction
there
was
they'll
definitely
be
flash
loans
on
on
like
different
layer
twos
as
well
as
layer
one,
but
we
lose
single
block
composability
when
we
cross
a
domain
so
that
that
inhibits
a
bit
our
current
oxygen
mechanism.
Although
our
auction
mechanism
doesn't
necessarily
need
to
be
leveraging
single
block
composability,
but
it
will,
you
know,
it'll
prevent
the
stronger
use
cases
where,
where
that
is
being
leveraged
but
yeah
to
chris's
point.
E
If
we've
done
our
jobs
right,
then
the
risk
parameters
on
each
domain
should
account
for
the
liquidity
available
on
those
domains.
Yeah.
I
guess
the
the
the
fanciful
case
is
like
let's
say,
options
are
running
pretty
hard
on
layer
one,
but
most
users
have
moved
liquidity
to
layer.
Two
and
there's
still
a
ton
of
positions
on
layer.
One
you
know:
can
we
easily
get
liquidity
back
from
layer
two
to
service
those
options
on
layer,
one
right
so,
and
the
answer
is
maybe
maybe
we
can't?
E
A
C
We'll
have
some
time
out
where
I
think
what
this
person
is
talking
about
is
like
if
the
oracles
lied
and
somebody
minced
them
die,
and
it's
not
going
to
be
backed
later
by
the
die
that
goes
through
the
slow
path.
In
that
case
yeah,
we
would
have
some
sort
of
longer
delay
where
we
would
say:
okay,
if
it
hasn't
come
in
by
this
time,
we're
gonna
have
to
push
it
as
bad
debt
to
the
to
the
vow.
B
B
We
have
other
solutions
using
state
channels
like
connex
or
a
few
others,
so
our
solution
is
definitely
much
more
similar
to
hop
than
to
regular
state
channel
solutions.
So
hop
hop
is
quite
similar
in
the
way
that
they
do
have
some
kind
of
keepers
bonders
that
move
that
for
many
users
between
domains.
B
But
the
problem
is
that
hop
doesn't
have
a
way
to
interact
with
the
native
tokens
right
like
if
they
want
to
move
die
using
some
like
they.
They
cannot
just
mean
die
on
any
domain
right,
that's
the
problem
with
with
hop,
and
they
cannot
mean
any
token
on
any
domain
really,
like
a
native
token,
canonical
token
right.
What
they
can
do
is
introduce
their
own
token
and
meet
that
one,
and
that's
exactly
what
they're
doing
they're
calling
it
h
tokens
and,
for
example,
you
have
hdh
ether
right.
B
So
the
problem
is
that,
then
you
need
to
introduce,
like
some
kind
of
way
to
swap
between
h
tokens
and
normal
tokens.
So
basically
they
have
like
stable,
swap
amms,
and
this
leads
basically
to
some
capital
inefficiencies
right.
Basically,
you
need
to
have
over
300
over
characterization
to
move
like
one
one
token-
and
this
is.
G
B
C
Another
piece
I'll
add
just
again
about
this
sort
of
fungible
debt
piece
is
that
we
get
a
massive
amount
of
scaling
with
this
sort
of
design
they're
not
having
to
close
out
transactions.
One
to
one
on
l1
is
is
super
super
important,
and
so,
by
having
this
fungible
debt,
we
can
scale
basically
infinitely
as
well
with
the
number
of
transact.
B
Yeah
exactly
this
is
also
something
that
we
do
slightly
different
than
other
solutions,
like
other
solutions
have
usually
like
some
kind
of
number
of
transactions
that
they
batch
and
we
we
don't
care
about
that.
So
that's
also
really
nice.
So
there
was
a
question
about
like
permitting
die,
so
this
is
about
like
deploying
mcd
on
at
different
domains
in
general,
so
yeah.
Maybe
we
can
talk
about
this
now.
So
so
let
me
let
me
answer
this
quickly.
B
So
basically,
our
approach
to
deploy
mcd
on
a
different
domain
is
that
so
the
the
the
problem
is
that
when
you
move
die
to
optimism
and
arbitrary,
now
you
always
deposit
die
on
their
one,
and
then
you
mean
I
mean
our
bridge
means
for
you.
The
same
amount
of
l2
die,
optimus,
die
or
arbitrary
right.
So
this
bridge,
if
there's
like
a
total
number
of,
I
don't
know,
one
million
die
on
on
optimism.
B
So,
if
users
use
this
die
this
mcd
instance,
let's
say
that
it
has
10
million
die
dead,
singing
and
you
know,
there's
suddenly,
like
11
million
die
minted
on
optimism,
but
only
1
million
die
locked
in
the
bridge.
This
means
that
users
wouldn't
be
able
to
move
from
layer
2
from
optimus
to
mainnet
or
to
arbitrary
right.
So
we
are
developing
the
system
to
avoid
exactly
this
problem.
This
is
like
that
the
biggest
problem
that
we
need
to
keep
in
our
minds
to
while
moving
up
mcd
to
different
domains.
B
So
the
solution
that
we
we
want
to
take
is
that
we're
gonna
pre-meant
die
available
on
on
particular
layer,
two
first
on
layer,
one
and
and
move
this
liquidity
this
die
to
locking
in
in
the
bridge.
So
if
we
deploy
new
mct
instance
with
that
10
million
die
dead
ceiling
on
on
particular
domain,
we
would
prevent
this.
10
million
die
on
layer,
one
and
lock
it
into
the
bridge.
B
So
even
though,
like
no
one
minted
really
die
on
on
layer
two,
yet
right
like
we're,
gonna
prevent
it
so
and
then
we
just
redistribute
it
rather
than
mint
on
there
too.
So
we're
gonna.
You
know
this
can
be
done
in
a
trust
us
manner.
When
you
know
this
die
is
always
locked
in
the
bridges
and
they
it
can
never
like.
You
know
it
never
goes
for
any
multiseeks
or
whatever
right.
B
So
so
this
way
this
bridge
never
runs
out
of
die
like
it's
not
possible
for
for
this
bridge
to
run
out
of
dice.
So
dye
is
always
like
fully
fungible.
You
can
take
dye
from
optimism
and
move
it
to
our
bedroom
or,
to
you
know,
zika
sink
in
the
future
and
so
on.
So
yes,
this
is
a
solution
to
that
problem,
and
there
were
some
questions.
Yeah,
so
much
is
asking
is
die
locked
in
layer,
one
bridge
equal
to
layer
to
that
thing.
B
G
Chris,
I
can
speak
to
this.
I
just
didn't
want
to
interrupt
what
you're
saying
before
I
was
just
commenting.
You
mentioned
that
the
risk
falls
to
the
mkr
holders
not
to
the
die
holders,
and
I
totally
agree
with
what
you
were
saying
that,
but
I
think
there's
an
important
copy
out
there
that
it's
during
normal
operation
that
that
risk
falls
in
that
way
during
emergency
shutdown
when
die
holders
try
to
redeem
their
die.
C
C
H
H
C
That's
what
I'm
trying
to
do
so
in
the
wormhole
case,
so
we're
minting
it
and
there's
no
token,
but
there
is
sort
of
just
it's
just
kind
of
to
simplify
things
but
mentally
you
can
consider
it,
as
the
token
is
a
nft,
a
future
promise
of
the
debt
being
paid
in
seven
days
or
whatever.
So
you
can
think
of
that
as
the
wormhole
is
backed
by
that
it's
just
we're
kind
of
ignoring
it,
because
it's
kind
of
all
internal
to
maker.
C
H
D
I
think
there's
another
way
of
asking
a
similar
question
and
I
think
what
what
you
were
asking
just
a
moment
ago,
so,
if
the
collateral,
if
you've
got
dye,
that
gets
minted
from
eat-
and
this
is
on
a
layer
too-
is
there
an
aspect
to
this?
Where
really
the
kind
of
the
difference
between
like
an
optimistic
roll-up
and
a
zero-knowledge
roll-up,
where
it
kind
of
plays
into
the
risk
factor
of
the
way
you
were
just
saying
about
die
needing
to
be
repaid
in
the
future.
C
H
Yeah,
let's,
let's
talk
about
this
blow
up
a
little
bit
because
I've
been
thinking
about
this-
is
that
in
the
loosest
sense
and
with
the
l2s
you're
kind
of
rolling
these
things
up.
You
know
that
you
have
l1
security
on
a
lot
of
stuff,
but
then
the
question
is:
where
does
the
real?
Where
does
the
collateral
really
sit
in
an
mcd
on
an
l2
right?
H
And
you
go.
What
do
you
do
right?
How
do
you?
What
do
you
do
if
anything,
to
make
these
people
whole
or
where
did
the
collateral
go?
I
mean
you
know
the
collateral's
gone,
it's
like
how
do
you,
how
are
you
gonna,
fill
the
void?
Basically
with
what
yeah?
So
that's
the
real
question,
I
think
we're
asking.
C
Yeah
what
would
happen
so?
Let's
say
we
have
eth
bridge
to
optimism.
So
in
the
in
the
sort
of
normal
case
the
bridge
is
sort
of
hopefully
developed
well
and
it's
not
doesn't
have
any
bugs
or
anything.
You
put
your
ether
in
the
east
bridge,
which
is
completely
separate
outside
of
our
system,
and
then
you
get
a
token
on
l2.
That
is
as
long
as
the
bridge
is
functioning
correctly
and
the
security
models
are
all
good.
That's
fully
fungible
with
the
ethon
l1.
So
we
would
use
that
as
collateral.
C
It's
not
exactly,
but
it's
like
pretty
close,
and
we
use
that
as
collateral
on
optimism.
Mcd.
Now
the
oracles
need
to
take
into
account
that
let's
say
there's
a
bug
and
somebody
drains
the
l1
side
of
that
ethbridge
and
now
ethon
optimism
becomes
worthless
because
you
can't
redeem
it.
That
would
be
a
case
just
where
each
price
on
optimism
goes
to
zero
and
we
would
liquidate
the
volts.
We
would
not
get
anything
in
return
because
it's
gone
to
zero
and
we
would
just
take
the
loss.
H
We
saw
the
story,
you
know
when
you
have
a
surplus
buffer,
that's
negative,
which
might
not
even
be
negative
at
the
time
that
this
dye
to
cover
the
loss
may
still
have
to
wind
its
way
around,
so
to
speak,
that
you
run
around
in
principle
with
dye.
That's
unbacked,
right
and
so
hazards
all
die
across
all
chains,
including
l1
in
the
loosest
sense,
and
I
was
trying
to
think
of
a
way
to
compartmentalize
this
risk.
But
the
problem
is:
is
dye
is
ubiquitous,
so
it's
entirely
unclear.
You
know
dion
and
optimism.
C
Yeah,
just
because
the
dye
is
fungible,
though,
doesn't
mean
we
would
just
like
nuke
the
whole
system,
so
in
this
case,
where
there's
a
catastrophic
bug
in
eth.
Basically,
what
would
happen
in
the
worst
case
is
the
optimism
mcd
would
max
out
the
debt
ceilings
for
eth.
There
would
take
a
maximum
die
loan.
That
diet
would
still
be
fungible
with
l1
and
maker
would
just
take
a
loss
into
in
the
amount
of
the
debt
ceilings
of
that
particular
roll-up.
So
it
would
be
contained
to
those
debt
ceilings.
D
So
that
that
that
same
following
on
that,
thinking,
though,
is
and
again
I
know
it's
an
edge
case,
but
it's
still
worth
going
down
like
with
an
optimistic
roll
up.
There
is
a
chance
that
it
just
whatever
it
get
it
explodes,
does
that
same
type
of
risk
factor
happen
with
a
zero
knowledge
roll
up
aka.
Will
we
end
up
with
a
debt
ceiling
on
optimistic
roll-ups?
That's
I'm,
making
up
a
number
10
million
and
the
zero
knowledge
roll
up
would
be
10
billion.
C
B
G
B
The
the
problem
with
the
you
know,
with
some
kind
of
hack
or
attack
on
the
chain,
wouldn't
be
probably
related
to
you,
know
theoretical
assumptions,
but
rather
to
some
practical
bugs
in
the
implementation
and
truth
to
be
told,
optimistic
apps
are
much
simpler
to
implement
and
that's
why
I,
I
think
that
this
argument
can
be.
You
know,
done
in
a
totally
opposite
direction,
like
zika
roll-ups
introduce
like
all
of
this
crazy
map
that
no
one
understands
and
so
on
and
so
on.
D
D
I
don't
remember
what
the
technical
term
is
whenever
it's
deemed
like
certain
finalized,
and
some
of
that
I
mean
I've
even
heard
that
that
that
window
is
going
to
be
compressing
after
the
migration
of
proof
of
stake,
where
the
the
economic
equivalence
goes
down
from
whatever
10
days
down
to
like
six
hours,
and
at
that
point
then,
then
I
agree
with
you.
The
challenge
is,
and
that's
my
only
question-
is
that
window
of
where
it's
not
deemed
as
finalized.
There
is
exposure.
B
F
B
No,
no
any
any
domain
like
then
in
theory,
worst
case
scenario
is
that
all
the
dye
that
were
in
the
bridge
was
stolen
and
collateral
was
also
stolen,
that
clatera
that
used
to
back
this,
this
dye
that
was
produced
on
layer
two
so
potentially
like
the
losses
like
we
don't
care
about
the
clutter
that
was
for
the
die
that
was
in
the
bridge
manually
breached
by
users,
and
that
was
stolen
because
it's
still
properly
backed
by
some
collateral.
But
we
worry
about
the
dye
that
was
minted
on
layer.
B
Two
and
you
know
then
collateral
doesn't
exist
or
someone
stole
it
and
we
have
basically
unpacked
dye.
So
in
cases
like
this,
basically,
whatever
was
minted
on
there
to
whatever
whatever
was
prevented
on.
There,
too
is
like
our
bad
debt,
and
this
is
potentially
this
can
potentially
be
really
hard
to.
You
know
contain
within
a
cypress
buffer
or
something
like
this,
so
yeah.
A
B
So
on
layer
one,
we
cannot
burn
like
this
diet.
That
was
minted
right,
like
it's
just
there,
and
we
cannot
do
anything
like
I
assume,
like
I'm
talking
about
situation
when
we
prevent
100
million
die,
we
send
it
to
the
bridge
and
then
somehow
domain
becomes
malicious
and
sends,
like
a
you,
know,
malicious
message
to
layer.
One
bridge
like
send
this
die
to
to
some
objects
right
and
basically
this
address
holds
a
die
on
layer,
one
that
it's
uncollateralized
like
if
the
domain
works
properly.
B
It
should
never
happen
right
because
we
have
these
guarantees,
but
of
course
this
guarantees,
like
you
know,
from
technical
point
of
view.
There
can
be
a
bug
or
something
and
then
then
we're
screwed,
but
yeah
it's
not
about
the
die
wormhole.
It's
about,
like
you,
know,
die
on
mcd
on
on
different
domains.
H
Well,
wait
a
second,
I
think
I
think,
there's
a
clear
answer
right
is
that
you're
right,
the
collateral
disappears
in
the
bridge.
Right,
you
could
say:
that's
somebody
else's
collateral.
We
don't
have
to
worry
about,
even
though
it's
the
backing
collateral
for
the
dye,
it's
the
dye.
We
have
to
worry
about
and
in
such
an
event,
you
know
when
you
know
the
system
know
that
has
uncollateralized
eye
out
there.
H
B
H
Yeah,
but
his
answer,
his
point
was:
was
that
we're
gonna
somehow
have
to
burn
that
dye
with
our
own
assets
so
that
we
can
bring
up
the
collateralization
or
the
better
way
to
put
it
is
to
reduce
the
dye
in
circulation
to
match
the
collateralization
that
we
know
is
in
effect
right
and
so
in
principle,
in
this
kind
of
event,
maker
actually
ends
up
eating
the
dye
loss
because
we
dye's
fungal.
You
know
we
don't
have
any
control
over
it.
H
Basically,
you
have
two
issues
and
that
you
also
said
one
issue
is
just
the
surface
area
of
the
bridge,
mechanics
right
that
those
could
get
hacked
in
different
ways
different
times
and
the
other
one
is
the
security,
the
closing
of
the
loop
on
the
security
right.
When
you
get
finality,
then
you
can
say.
H
Look
I
finally
closed
the
loop,
like
what
map
was
saying
and
he's
saying
that
basically
there's
a
latency
loophole
right
that
that
loop
closing
is
when
there's
an
open
security
attack,
not
just
from
the
surface
area
the
protocol,
but
from
the
loop
being
closed
in
security.
And
so
those
are
two
things
where
we
basically
can
lose
that
that
die
and
and
that's
where
the
hazard
is
and
that's
what
we
have
to
weigh
in
terms
of
risk.
Right.
C
C
C
C
B
H
I
like
that,
as
a
bug
bounty
now
have
you
guys
talked
to
growth
at
all
in
terms
of
like
what
amount
of
dye
on
these
l2s
is
considered.
A
good
number
for
free-flowing
liquidity
right,
I
assume,
like
one
to
two
million,
is
like
nothing.
50
million,
maybe
is
a
reasonable
number
does
it
have
to
be.
Of
course
we
want
to
grow
it,
but
what
is
a
reasonable
number
for
some
of
these
l2s
in
terms
of
giving
a
decent
die
liquidity
to
be
able
to
punch
through
here?
What
do
you
guys
think
or
what's
the
opinion.
C
H
You
know
secure
loan
against
the
die
in
these
l2s,
and
so
what
we
could
do
is
we
could
make
out
these.
Usually
this
v2amm
liquidity
is
kind
of
the
backing
liquidity
you
know
so
that
it
has
die
in
the
contract
right,
it
can
go
up
and
down.
It
has
maker
that
could
be
sold
and
it
could
actually,
in
effect,
you
know
if
people
could
put
enough
in
there
and
we
did
the
right
stuff
with
it.
We
use
it
as
like
the
tier
one
liquidation
against
the
assets.
H
You
know
it
stands
as
the
secured
collateral
on
the
base.
You
know
so
that
all
maker
doesn't
have
to
come
under
the
gun,
just
a
sufficient
fraction
of
it,
and
so
it's
the
loosest
way
that
you
can
kind
of
limit
the
the
losses
as
to
have
like
a
tier
one
class
that
takes
the
hit
before
everything
else
does.