►
From YouTube: EIP-1559 Wallet Interfaces Call (Breakout #9)
Description
A
Okay,
we
are
recording
yeah,
so
trent,
I
see
you
shared
the
agenda.
One
thing
also
you
mentioned
is
that
a
couple
teams
have
like
mockups
and
whatnot
that
they've
been
working
on
and
I
think
they've
shared
with
you.
I
don't
know
if
it
maybe
makes
sense
for
like
teams
who've
actually
like
prototype
stuff,
maybe
take
five
minutes
or
ten
minutes
to
walk
us
through
it.
I
feel
like
that
might
be
a
good
way
to
set
the
context.
A
I
don't
know
if
you
know
now
that
it's
recorded
that
changes
things.
Otherwise
we
could.
We
could
kind
of
go
through
the
agenda
or
just
like
the
questions
that
people
had
but
yeah.
I
feel
like,
if
a
team
kind
of
wants
to
walk
through
what
they've
thought
about
so
far
and
how
they've
kind
of
approached
things
that
might
be
useful
to
make
it
a
bit
more
concrete
than
yeah
just
talking
in
the
abstract.
B
C
All
right
so
so
yeah
we
have
we've
had
a
lot
of
conversations.
This
is
this
is
very
much
a
rough
draft.
We're
we're
hoping
to
do
some
user
testing
really
soon,
probably
by
the
end
of
this
week,
so
we'll
probably
probably
be
iterating,
there's,
probably
a
lot
of
things
that
are
going
to
change
or
things
that
don't
make
sense.
But
here's
where
we're
at
so
the
scenario.
C
This
is
sort
of
a
stripped-out
view
just
to
keep
it
simple.
The
scenario
is
focused
on
swap
so
we're
showing
unit
swap
here
some
of
the
like
we're
thinking
about
what
changes
in
different
network
conditions.
If
if
traffic
is
increasing
versus
decreasing,
so
this
scenario
is
kind
of
focused
on
an
increasing
increasing
traffic,
so
we're
sort
of
estimating
the
fees
are
going
to
be
going
up,
there's
a
little
bit
of
a
wider
range,
so
you
go
through
you
hit
swap
on
unit
swap
this
is
the
revised
transaction
screen.
C
So
there's
really
only
two
pieces:
we've
we've
changed
we're
calling
it
an
estimated
gas
fee.
This
is
what
we
expect
you
to
pay,
and
then
there
is
a
range,
so
that
range
would
be.
If
you
know,
if
the
network
traffic
didn't
continue
in
the
direction,
we
did
maybe
it's
a
little
bit
less
and
then
the
top
end
would
be
sort
of
your
your
max
fee
and
then
down
here
we're
showing
the
total
we're
highlighting
the
estimated
amount.
C
I
think
a
lot
of
that's
going
to
depend
on
how
confident
we
feel
about
that
number.
We
don't
want
to
show
a
number
and
then
pay
something
else,
but
we
feel
confident
about
it
showing
highlighting
that
number
and
then
showing
it
up
and
then,
if
you
hit
edit,
that
brings
you
over
into
the
edit
view
the
the
way
we're
thinking
about
it
now
is
trying
to
shift
focus
from
speed
and
more
towards,
like
purpose
like
what
type
of
transaction
are
you
doing,
and
then
what?
C
How
much
should
you
be
paying
based
on
that,
so
some
we're
gonna
have
to
have
a
good
fallback.
So
we're
not
always
gonna
know
that
scenario
of
what
somebody's
doing,
but
our
hope
is.
We
can
you
know,
sort
of
understand
what
they're
doing
so
in
this
case,
they're
doing
a
swap
and
then
we'd
be
recommending
a
higher
setting.
C
C
C
B
C
C
Yeah,
absolutely
that's
one
thing
that
we
haven't
tackled
yet
and,
to
be
honest,
we
haven't
like
it's
been
in
my
head.
We
haven't
actually
talked
about
it,
but
this
will,
I
mean
we'll,
have
to
update
pretty
quickly
and
that's
something.
We
definitely
need
to
take
consideration
in
especially
on
this
screen
right.
F
C
Yeah,
that's
a
good
question.
We
did
in
some
of
our
earlier
months.
We
did
do
a
little
bit
more
messaging
around,
like
the
current
network
status.
Right
like
hey,
it's,
it's
really.
It's
really
busy
right
now,
like
fees
are
really
high,
we
did
consider
like,
like
sort
of
prompting
people
to
add
a
lower
lower
max
fee
and
waiting
for
it
or
you
know,
running
the
risk
of
it.
A
Yeah
there's
a
comment
about
like:
should
we
allow
opt-out
at
the
user
level
to
send
legacy
like,
I
think
it
might
make
sense
to
preserve
that,
but
like
there's,
no,
the
the
main
advantage
of
sending
legacy
transactions
for
the
users
is
the
fact
that
it's
like,
if
1559
is
not
supported,
say
they
use.
I
don't
know
like
ledger
and
ledger,
does
an
update.
We
want
the
network
to
be
able
to
have
their
transaction
or
say
they
signed
a
transaction.
A
A
year
ago,
right
they've
been
waiting
to
broadcast
it
for
a
year
and
they
threw
out.
You
know
whatever
thing
they
use
to
sign
it.
We
want
them
to
still
be
able
to
send
it.
So
I
you
know,
I
don't
see
a
like
use
case
for
like
allowing
users
to
like
never
like
to
not
have
1559
transactions
as
a
default,
but
there
might
be
some
weird
edge
cases
where,
like
in
the
advanced
settings,
you
want
somebody
to
be
able
to
dig
up
and
and
send
a
legacy
transaction.
A
But
if
you're
like
constructing
the
transaction
on
behalf
of
your
users,
there's
not
really
a
good
reason
to
send
a
legacy
transaction,
because
that
means
they're
just
going
to
pay
more
gas.
They
won't
get
a
refund
like
they
won't
get
the
difference
between,
like
their
fee
cap
and
the
base
unit
tip
refunded
to
them.
G
A
Yeah
the
short
answer
to
there,
so
there
was
a
thread
in
the
agenda
about
that.
I
think
at
this
point
the
like
easiest
way
is
you
look
at
the
block
header
and
see
if
there's
a
base
key
in
it.
Unfortunately,
there's
no
way
to
know
that,
like
a
network
will
support
something
in
the
future,
so
you
can't
like
say
we
we
announced
the
fork
you
know
tomorrow.
A
H
E
Okay,
great
so
trying
to
keep
things
initially
as
close
to
what
exists
now,
rather
than
giving
people
ranges
of
fees
when
they're,
when
they're
choosing
the
priority,
which
only
showing
them
the
maximum
that
they're
going
to
be
paying
for
that
transaction
and
then
kind
of
behind
this.
We
do
have
all
of
the
custom
all
of
the
custom
stuff,
so
we're
giving
them
information
about
the
current
base,
feed
gas,
limit
per
gas
tip
limit
and
per
gas
price
limit
and
then
calculating
the
the
maximum
fee.
E
So
if
the,
if
the
user
sets
a
tip
that
is
below
the
currently
accepted
tip,
then
we're
showing
them
a
warning
around
the
the
minimum
tip
of
the
last
n
or
last
x
box
and
the
average
tip
that
is
being
given
to
the
miners,
if
it's
above
the
minimum
but
below
their
average.
Here
we're
giving
them
information
about
that.
E
If
I
go
ahead
a
little
bit
further
and
then
there
are
an
additional
set
of
edge
cases
where,
if
somebody
sets
a
a
a
base
fee,
that
is,
that
is
above
the
current
base
fee
but
lower
than
the
the
current
tip.
Then
again,
we
can
assume
that
that
transaction
won't
be
accepted
initially
and
then
again,
an
edge
case
for
for
for
when
the
calculated
tip
is
going
to
be
below
that
average.
E
There
are
also
kind
of
combinations
of
these
edge
cases
as
well.
So
if
the
tip
is
too
low-
and
oh
sorry,
I'm
reminding
myself
of
these
screens
as
I'm
running
through
them,
if
the
tip
is
too
low
and
the
the
overall
limit
is
too
low,
then
we
need
to
also
show
them
information
about
what
is
happening
in
those
specific
situations.
E
E
With
regards
to
romo,
we
had
a
discussion
about
this
earlier
today
and
after
reviewing
the
document
around
how
it's
going
to
be
released
and
kind
of
initially
having
the
one
queen
base
fee
and
still
having
the
auction
mechanism.
We
at
least
imagine
that
keeping
the
current
gas
interface
is
going
to
be
the
best
thing
to
do
for
the
initial,
let's
just
say,
50
blocks
and
then
switching
to
this
to
this
new
interface.
E
E
Ideally,
we
chatted
about
this
today
as
well,
is
we'd,
have
a
test
room
to
make
sure
that
all
of
this
is
going
to
work,
we're
not
in
a
in
a
position
to
a
b
test,
this
interface
against
the
current
interface,
because
it
is
going
to
go
live
and
we
need
to
accommodate
for
it.
We
can't
we
can't
have
the
the
the
current
gas
interface
tested
against
the
new
interface
just
because
the
the
current
gas
interface
doesn't
doesn't
like
cover
all
of
the
parameters
that
that
people
can
manage
themselves.
E
That
being
said,
somebody
mentioned
earlier
being
able
to
switch
the
interface
to
use
the
current
gas
format,
and
I
think
that
is
something
that
we
don't
have
in
here
and
that's
something
that
we
probably
should
have
in
here,
but
yeah
a
b
testing.
I
don't
think
we're
in
a
position
to
do
that.
With
this.
B
E
Yeah
yeah,
that
would
be,
that
would
be
really
helpful.
We
are
gonna
run
through
this,
make
sure
that
everything
is
usable
and
make
sure
that
people
understand
what
is
happening
after
we've
got
a
initial
build
ready
and
but
but
the
main
things
that
I
imagine
is
changing
are
going
to
be
the
the
the
copy
that
we're
using
in
these
edge
cases.
E
We
don't
know
how
to
estimate
the
priority
fee.
So
what
is
low
priority?
What
is
high
priority?
We
still
need
to
figure
out
that
part
of
it
and
I'm
not.
I'm
not
sure
how
we're
how
we're
gonna
do
that
that
isn't
really
a
something
that
I'm
I'm
qualified
to
talk
about,
but
yeah.
I
think
it's
bigger
gnome
until
we
start
to
learn
after
it
goes
live.
A
So
we
have
some
values.
I
don't
know
if
you
saw
that
she
sheet
that
trent
and
I
put
together,
we
have
like
some
rough
values
for
the
priority
fee
that
that
we've
used.
So
basically
the
challenge
for
the
priority
fee.
Is
you
want
to
compensate
miners
enough
that
they,
you
know
it's
worth
it
for
them
to
add
their
transaction
and
the
more
transaction
miners
add
in
the
block
the
higher
the
risk
of
being
uncold
is,
and
this
used
to
be
quite
simple
to
calculate.
A
But
now
a
large
part
of
the
uncle
risk
is
mev
bundles.
So
if
a
miner
has
an
mev
transaction
in
their
block,
that's
like
a
high
value
time,
sensitive
transaction,
so
that
the
cost
of
the
opportunity
cost
of
these
transactions
is
much
higher.
So
in
the
in
the
cheat
sheet,
you
can
see
there's
like
a
a
graph.
Basically
that
shows
like
a
linear
relationship
between
like
what
the
average
mev
in
a
block
is,
and
you
know
what
should
the
tip
be.
Flashbots
has
a
dashboard
that
kind
of
tracks
this
over
time.
A
There's
no
great,
like
library
right,
like
there's
no
great
way
to
like
plug
in
that
dashboard
in
in
wallets,
but
you
know
if
you
want,
like
a
ballpark
value
to
start.
What
I
would
do
is
like
looking
at
the
flashback
dashboard,
you
know
a
week
or
two
before
the
eve
goes
live
and
you
just
kind
of
you
can
kind
of
ballpark.
A
You
know
like,
what's
the
average
med
in
blocks,
then,
and
and
then
you
know,
you
can
go
back
to
the
graph
and
figure
out
like
what's
like
the
right
tip
right
now,
that
value
would
be
about
two
way
but
they've
anyways
flashbacks
rolled
up
a
bunch
of
optimizations
that
will
allow
for
more
mev
and
each
block.
So
I
suspect,
by
the
time
it
goes,
live
like
a
decent
tip
for
most
transactions
is
probably
going
to
be
like
three
way
again
subject
to
like
how
that
the
muv
evolves
and.
E
A
Also,
I
think
right
now,
there's
only
like
something
like
30
or
40
percent
of
blocks
that
have
mevs
so
you're
slow.
You
could
probably
set
like
a
tip
to
like
two
way,
which
or
I
forget,
if
it's
one
or
two
guy,
it
says
that
the
spreadsheet
but
that'll
compensate
basically
for
blocks
with
zero
ibv,
so
your
slow
can
basically
just
be.
You
know,
you're
wailing
until
there's
a
block
that
doesn't
have
mvv
in
it,
which
you
know
on
average,
should
be
two
three
blocks
yeah.
E
Well,
so
there's
that
and
there's
also
the
base
view
whether
our
base,
I
mean,
I
know
we-
can
determine
whether
the
base
b
is
going
to
go
up
or
down
based
on
activity,
but
also
I
we
then
need
to
make
a
call
on
what
a
low
priority
base
fee
is
going
to
be
versus
a
high
priority
base
fee
and
then,
hopefully
in
the
future.
We
can
estimate
time
based
on
that,
but
there
are
so
many
variables
and
so
many
moving
parts
that
it's
really
difficult.
E
I
I
can't
right
now
say:
okay,
we
know
what
is
going
to
happen
ahead
of
time,
so
this
is
very
much
kind
of
the
absolute
minimum
that
we
can
do
initially
to
cover
for,
like
the
parameters
and
and
everything
that's
required
as
a
part
of
it
and
then
hopefully
in
the
future.
We
can
introduce
estimation
on
time
yeah
just.
A
Yeah-
and
I
think,
having
unchained
data,
like
you
know
like
even
like
a
few
weeks
of
launching
data,
will
be
massively
useful
to
see
what
you
know
what
the
right
defaults
are
yeah.
If
you,
I
don't
know
how
much
like
you
know,
tracking
you
do
of
like
user
data.
But
if
you're
able
to
see
like
this
transaction
failed
or
you
know,
got
stuck
pending
and
and
what
not
like.
E
So
that's
a
situation
that
I'm
a
little
bit
nervous
about,
and
that
would
be,
let's
just
say
day,
one
the
suddenly
high
congestion
lots
of
people
are
trying
to
transact
and
you
essentially
have
a
bidding
war,
then
between
different
wallets
and
what
I
I
on
the
state
decide.
We
don't
want
to
be
in
a
situation
where
our
estimation
is
totally
off
and
nobody
can
get
the
transaction
through
from
from
stateless
music
using
the
simple
interface
and
yeah.
I
guess
that's
for
us
to
figure
out,
but.
A
A
really
good
point
so
on
so
this
was
like
the
last
thing
I
put
in
on
like
the
cheat
sheet,
but
when
1559
goes
live
the
base
fee
is
actually
set
to
one
way,
which
is
tiny.
So
that
means
there
will
be
a
period
where,
like
blocks
will
be
full
just
because
you
know
there
will
be
this
bidding
war,
so
I
suspect
the
easiest
way
for
wallets
to
get
around.
A
That
is
to
actually
wait
to
display
the
1559
ui,
and
you
basically
want
to
wait
until
like
blocks
are
not
like
completely
full
again,
and
I
you
know
I
had
some
rough
like
ballpark
numbers
there.
It's
probably
something
like
you
know,
15
30-ish
minutes
and
I
had
like
some
better
criteria
but
like
so,
I
think,
once
you
have
that
initial
spike
you'll
probably
get
to
a
spot
where,
like
yeah,
you
are
not,
you
are
no
longer
like
a
bidding
war
and
like
prices
are
stabilized,
and
so
the
1559
ui
should
work.
E
Yeah
yeah,
so
what
yeah?
At
the
start
of
the
call
I
mentioned,
we're
going
to
possibly
keep
the
current
interface
or
the
current
estimation,
interface
for
the
first
50
box
and
then
switch.
Hopefully
that
keeps
things
simple,
but
obviously
want
to
double
check
that
that
sounds
right
with
everybody
here.
A
Yeah,
so
the
trade-off
there
is,
if
you
leave
it
just
too
long,
you
know
users
might
over
pay
slightly
under
transactions.
So
I
think
you
know
you
could
say
like
you
want
to
be
really
safe
and
you
put
it
for
100
blocks.
So
that
means
for,
like
those
you
know
second
50
blocks,
maybe
your
users
are
overpaying
a
little
bit,
but
they're,
not
you
know,
potentially
getting
your
transactions
stuck.
So
I
think
that's
just
like
the
yeah.
The
trade-off
you
like
every
wallet
basically
needs
to
figure
out
yeah.
A
I
guess
yeah
we're
almost
like
halfway
through
the
call.
We
did
have
like
a
bunch
of
topics
on
the
agenda,
but
I
don't
know
if
just
to
make
it
like
as
useful
as
possible.
Are
there
like
urgent
questions
or
things
that
you
know
people
here
really
wanted
to
bring
up?
Otherwise
we
can
run
through
the
different
topics,
but.
L
I
guess
I
had
a
question,
so
I
assume
most
people
are
relying
on
gas
apis
right
now,
just
to
determine
kind
of
what
the
best
price
is
and
there's
various
apis.
I
know
that
the
wallets
are
on
this
call.
I
was
wondering
if
you
guys
were
having
conversations
with
these
various
gas
apis
to
help
provide
estimations
for
for
tip
calculations
when
it
gets
to
the
point
where
we
need
to
start
bidding
again
against
each
other
or
like
if
there
are
plans,
for
that.
B
B
A
H
Sure
I
mean
so
first,
the
thing
to
remember
is
well,
we
don't
have
data
yet,
but
there
is
a
very
strong
intuition
that
these
bidding
wars-
they
will
be
very
infrequent
and
when
they
do
happen
they
will
be
very
short-lived,
because
if
there's
a
lot
of
pressure
basically
raises
and
that's
after
some
point
it
kind
of
stabilizes
the
system.
So
the
role
of
the
oracles
to
give
you
the
tip,
is
very
different,
like
the
oracles
as
they
exist
right
now.
H
They
do
this
very
long,
historical
kind
of
analysis,
the
last
200
blocks
of
data
here
I
don't
actually
think
it's
necessary.
First,
I
think
it's
good
enough
to
look
at
the
five
ten
latest
blocks
and
kind
of
look
at
the
median
fee.
How
people
are
let's
say
over
beating
each
other?
You
don't
need,
I
think,
the
complexity
that
currently
exists
in
this.
H
If
gas
station
oracles
or
any
other
oracle
you
might,
it
might
be
useful
to
have
something
where
you
actually
see
the
pending
transactions
and
you
can
see
what
people
are
currently
planning
to
tip.
But
apart
from
that,
I
I
feel
that
yeah
oracles
in
under
1559.
They
really
don't
serve
the
the
same
purpose
as
they
used
to,
and
my
point
about.
H
The
records
was
more
that
these
legacy
users,
who
maybe
use
outdated
software
if
they
still
rely
on
oracles,
the
oracles,
will
start
very
much
converging
towards
the
current
value
of
base
fee,
and
that
makes
it
a
pretty
bad
estimation
for
users
who
are
still
using
legacy
transactions,
but
but
otherwise,
I
think
oracle
should
either
be
yeah
sunset
or
or
very
much
like.
We
thought
from
from
scratch
into
the
1559
environment.
H
Yeah,
that's
correct,
but,
okay,
at
this
point
it
seems
very
much
less
sophisticated
on
chain
by
on
chain.
I
really
mean,
like
the
wallet
itself,
could
just
keep
in
mind
the
last
five
ten
blocks
and
make
the
estimation
itself.
I
feel
that
might
be
good
enough
for
one
five,
five,
nine
and
you
wouldn't
need
all
the
machinery
that
exists
in
the
current
of
chain,
oracles
that
we
have.
H
B
A
Yeah,
I'm
looking
through
barnabas
notebooks
repo
right
now,
but
there's
like
20
of
them
so
yeah.
If
yeah,
I
remember
barnaby,
you
had
one
kind
of
walking
through
the
oracles
and
how
like
the
data
from
even
like
how
the
data
from
the
1559
usage
could
even
help
set
better
oracles
for
like
the
legacy
transactions.
A
H
I
guess
right
now:
transactions
they
have
very
wide
range,
even
within
blocks
and
so
oracles.
They
they
quote
like
the
slow
versus
medium
versus
fast.
There
can
be
like
a
very
large
variance
between
the
three
different
levels,
and
I
don't
think
we'll
see
that
in
one
five,
five-
nine,
because
by
the
nature
of
a
mechanism
which
is
like
this
base
fee,
that
everyone
is
paying
plus
a
premium,
that
everybody
pretty
much
pays
the
same,
you
should
find
that
your
records
start
converging
to
to
a
good
enough
value.
B
And
for
the
people
asking
about
gas
now,
I've
had
some
difficulty
communicating
with
them
or
just
like
getting
them
on
board
with
this
stuff.
Not
that
they're
not
interested,
but
I
think
they're
just
doing
other
things.
So
if
anybody
has
like
a
existing
line
of
communication
with
them-
and
you
can
tell
them
to
talk
to
me
or
connect
us
in
some
way,
that
would
be
really
helpful.
N
Cool
one
thing
I
was
I
was
wondering
is
it
feels
like
pretty
much.
Everyone
is
on
the
same
page,
that
from
now
on,
most
of
the
estimation
side
will
be
on
the
on
the
wallet
side
right
just
looking
at
the
latest
vlog,
I
feel
like
that's
kind
of
okay,
but
at
the
same
time
it
will
be
cool
if
any
api
like
etherscan
or
whatever
could
provide
that
estimation
as
an
api.
N
I
do
because
polling
blocks
is
fine,
but
at
the
same
time
is
maybe
a
bit
intense
or
depending
on
network
connections.
Not
everyone
has,
like
you
know,
perfect
wi-fi
when,
like
there
is
more
more
chances
to
fail.
If
you
have
to
be
polling
constantly
to
know
something
versus
like
just
fetching
one
api
call
to
to
an
api
and
just
get
the
number
of
what
you
will
pay
right
now
I
don't
know
just
bring
it
up,
could
be
useful
for
the
apps
too.
So
I
don't
know
something
that
we
have.
F
And
sorry,
I'm
circling
back
to
what
bernabeu
was
mentioning
about
oracles.
I
understand
that
all
the
discussion
about
gas
price
circles
for
1559
is
around
the
minor
tip,
but
does
it
make
sense
to
also
have
an
oracle
for
base
fee
to
know
if
the
current
base
fee
is
extraordinarily
high
or
something
that
that
will
vary
on.
A
I
think
yeah
that
would
also
be
pretty
simple
to
build
right
because
you
just
need
to
look
at
the
gas
used
right.
If
you
know
more
than
n
blocks
are
full
right.
Basically,
the
amount
of
completely
four
blocks
tells
you
how
high
the
gas
key
is
on
like
an
exponential
scale.
So
it's
like,
if
you
see
you
know
one
full
block,
it's
probably
not
worth
it.
A
H
Yeah,
I
think,
if
you
observe
five
blocks
full
previous,
you
know
that
the
gas
fee
is
very
high
because
or
at
least
not
very
high,
but
very
much
there's
a
very
strong
demand
pressure
because
otherwise,
like
you,
couldn't
have
these
double
full
blocks.
Now
that
you
have
like
this
slack
mechanism,
so
yeah
five
full
blocks
is
definitely
like
an
indication
that
a
lot
of
people
want
to
transact.
At
the
same
time,.
A
B
A
Sure,
I
guess
yeah
okay,
so
the
first
stuff
was
the
json
rpc
changes.
So
basically
I
I'll
share
the
json
rpc
spec
in
the
chat
just
to
make
sure
everybody
has
it,
but
we've
added
the
changes
to
json
rpc
there.
In
short,
you
know
it
adds
the
base
sheet
to
the
block
header
and
it
adds
the
maxi
and
max
priority
fee
to
the
transaction
object
if
the
transaction
is
type
2,
so
like
a
1559
style
transaction.
A
So
that
should-
and
that's
basically
the
api
that
the
different
clients
will
implement.
I
think
geth
has
the
different
version
of
this
and
they
have
an
open
pr
to
implement
to
implement
something
in
accordance
with
the
spec,
but
that's
kind
of
yeah.
What
all
the
clients
will
will
implement
in
the
next
couple
weeks.
A
Recommended
minimum
priority
fees,
so
we
touched
on
this
quickly
again
there
I
think
the
the
case
where
there's
not
like
a
sudden
spike
in
demand.
What
you
probably
want
is
to
just
look
at
the
ballpark.
You
know
average
mev
in
the
last
seven
days
follow
barnabas
graph,
that's
linked
in
that
and
you
can
use
that
to
kind
of
set
the
the
default
tip
so
right
now,
you
know
with
the
values
that
were
seeing.
We
would
be
around
like
1.5
way
for
gas.
A
Again
I
mentioned
earlier
flashbots
is
you
know
doing
some
optimization
work
to
include
more
bundles,
so
I
suspect,
by
the
time
59
goes.
Live
like
two
way
for
gas,
as
a
default
tip
probably
makes
sense
to
get
your
transaction
included.
You
know
and
like
the
like
said,
you
know
75
percent
of
blocks
unless
it's
like
extremely
high
med,
so
just
as
a
default
option
to
gui,
as
of
today
is,
is
probably
the
right
amount,
I'll
just
run
through
it.
If
people
have
questions
just
please
interrupt
me.
A
Transaction
replacement,
so
okay,
so
this
is
something
again
get
has
an
open
pr
for,
but
the
one
challenge
with
1559
is
you
can
replace
transactions
kind
of
costlessly?
So
if
you
just
raise
the
fee
cap,
it
doesn't
actually
mean
that
the
user
will
end
up
paying
more
because
you
know
they
just
pay
the
basi
and
and
the
tip
they
don't
actually
pay
their
entire
fee
cap.
So
because
of
that,
it
could
be
like
an
attack
vector
where,
like
people
could
just
stand,
the
transaction
pool
raising
the
fee
cap.
A
You
know
every
time
and
it's
it's
cost
less
for
them
to
do
that,
whereas
today,
if
you,
if
you
raise
your
gas
price
on
every
transaction,
obviously
you're
paying
that
highest
price.
So
in
order
to
avoid
that,
I
believe
what
jeff
and
other
clients
are
going
to
go
with.
Is
you
need
to
raise
both
the
fee
cap
and
the
tip
by?
A
I
A
Just
part
of
the
clients,
so
like
sure
you
can
you
can
you
know,
jailbreak
your
client
to
submit
the
transaction,
but
then
nobody,
I
guess
the
clock.
Other
nodes-
will
not
replace
the
transactions
in
their
transaction
pool
if
they
see
that
it
hasn't
been
raised
enough
right
so
and
they'll,
probably
just
like
mark
you
as
a
bad
peer
or
something
so
it's
like
you
can.
You
can
obviously
hack
get
and
propagate
whatever
you
want
on
the
network,
but
then
other
nodes
will
just
not
update
their
their
status.
B
Yeah
we
touched
on
this
earlier-
I
just
added
it,
so
we
don't
need
to
necessarily
go
over
it
again,
but
like
definitely
these
ideally
like
you
won't
need
to.
If
you're,
if
you're,
making
the
transition
properly
like
regular
users
who
aren't
fee
sensitive
or
you
know,
are
just
sending
basic
transactions,
they
don't
necess,
they
don't
always
care
about
the
advanced
gas
estimation
tools.
So,
ideally
like
you've
worked
out
a
transition
plan,
but
in
in
the
case
of
you,
know
a
lot
of
crypto
users.
B
They
want
to
know
how
these
advanced
features,
work
and
I'm
sure
everybody's
already
thinking
about
this,
like
you
will
need
to
communicate
what
all
these
fields
are,
and
maybe
like
recommended
practices
for
how
to
set
things
during
congestion
yeah.
This
is
I
mean
I
don't
need
to
tell
people
this,
but
it's
like
I'm
sure,
you're
already
thinking
of
how
to
communicate
this
to
your
users.
A
Yeah
and
for
the
actual
kind
of
ui
switch,
so
we
talked
about
it
earlier.
You
know,
I
think,
there's
different,
there's
different
approaches.
You
can
take
the
like
easiest
and
like
most
naive,
one
is
just
like
adding
a
blocks
buffer
between
the
hard
fork
and
when
you
turn
on
the
ui,
so
like
you'll
know
the
hard
fork
block
well
in
advance,
and
you
do
like
that,
plus
you
know
100
or
plus
50
and
and
then
you
just
switch
it
on.
A
If
you
wanted
to
actually
base
it
on
network
condition,
one
you
know
there's
a
couple
metrics
you
can
look
at.
The
first
is
just
the
gas
used
in
the
block.
So
when
we
start
seeing
the
gas
used
actually
represent,
like
50
percent
of
the
gas
limit.
So
right
now
you
know
the
gas
limit
is
50
million
it'll
be
30
million
after
the
fork,
so
you'd
want
to
check.
You
know.
Have
I
seen
like
a
couple
blocks
of
the
the
gas
used
being
like
around
50
million,
rather
than
30
million?
A
That's
telling
you
that,
like
we've,
basically
processed
all
of
the
transactions,
you
know
for
a
certain
base
fee.
That,
basically,
is
not
like
a
good
gauge
of
demand
on
the
network.
If
you
want
to
just
look
at
the
base
fee,
you
know
one
way
to
do
that
is
like
maybe
just
waiting
to
see
like
one
or
two
bases
where,
like
the
parent
space
fee
is,
like
you
know,
pretty
close
to
the
current
base
fee.
A
A
Basically,
when
you're
cutting
the
release
for
whenever
your
product
is
going
to
go,
live
and
then
you
can
calculate
you
know,
how
long
does
it
take
to
get
from
one
way
to
there
if
the
blocks
are
full,
it
increases
by
twelve
and
a
half
percent
every
block.
So
when
I
did
the
math
it
was,
I
assumed
like
a
250
way,
which
is
obviously
higher
than
the
gas
price
today
and
I
gave
50
blocks.
A
But
you
know
you
can
just
look
at
the
blocks
whenever
your
release
is
closed
and
you
know
if,
if
you
want
to
be
extra
sure
you
can
like
use
like
a
combination
of
those
rules,
you
know
you
can
set
yourself
like
maybe
a
fairly
short
block
limit.
Like
say,
you
know,
like
50
blocks
since
the
fork-
and
you
know
you
want
the
gas
used
to
be
between
those
two
ranges
before
you
flip
on,
like
the
1559
ui,
and
I
guess
what's
nice
is
like
all
those
parameters
are
just
in
the
block
header.
A
Oh
sorry,
yeah,
so
erc
editors,
okay,
so
this
is
not
necessarily
related
to
59
but
kind
of
a
quick
pitch.
We
are
going
to
be
spilling
the
eip
repo
between
eips
and
ercs,
because
there's
just
like
such
a
different
skill
set
from
folks
working
on.
You
know
core
eips
and
folks
working
on
the
the
interface
level.
A
If
you
are
interested
in
helping
to
be
like
a
potential
erc
editor,
please
reach
out
to
trent
or
me
after
the
call
and-
and
we
can
chat
about
that,
but
basically
it
would
help.
You
know
maintain
the
the
repo
make
sure
that
there's
like
a
good
process
for
people
to
add
new
standards
and
whatnot
light
client
is
on
the
call
he's
like
a
eip
editor.
So
he
can
maybe
also
give
some
context
on
on
what
it's
like,
but
yeah.
B
I
know
etherscan
is
here
and
eat
gas
station,
but
if
that
is
a
need
and
people
want
us
to
organize
another
call,
we
can
do
that.
I
know
this
was
more
focused
on
wallets,
but
obviously
that's
very
tightly
linked
to
how
you're
serving
data
to
people,
so
maybe
just
after
this
I'll
reach
out
to
those
those
teams
and
see
if
we
need
to
organize
something.
O
O
A
O
O
A
The
challenge
yeah
the
the
challenge
with
eip
base,
so
the
the
reason
this
is
a
hard
problem
is
that
clients,
at
least
not
all
clients,
have
the
concept
of
like
an
eip
being
activated,
especially
with
mainnet,
and
that's
led
the
having
that
concept
has
led
to
bugs
before.
If
you
can
say
you
know,
I
want
eip
x,
y
and
z.
The
the
problem
is,
there's
often
a
lot
of
interplay
between
them,
and
so
what
clients
will
do
is
they
won't
say?
I
support
an
eip.
They'll
say
I
support
a
certain
hard
fork
right.
A
They'll
say
I
support
like
london,
or
I
support
berlin
or
whatever,
and
the
the
challenge
with
that,
then
is
like,
say:
ethereum
classic
ads
1559.
Their
hard
fork
is
not
going
to
be
called
london
and
they're.
Even
if,
if
they
you
know
their
heart,
work
is
not
going
to
be
called
london
and
it
might
not
be
the
exact
same
hard
fork
at
1559.
So,
for
example,
you
know
where,
in
london
we're
also
changing
a
bunch
of
gas
costs
or
sorry
every
refund.
O
A
Don't
know
so
the
clients
themselves
don't
keep
track,
of
which
eips
is
is
activated,
they
keep
tracks,
of
which
hard
forks
are
activated
right
and
like.
You
could
probably
create
a
mapping
from
that,
but
I
I
doubt
that
happens
for
london,
but
right
now,
if
you
wanted
to
like
easily
expose
some
data,
you
could
say
you
know,
does
get
have
london
enabled,
but
then,
on
the
wallet
side
you
need
to
have
like
some
mapping
that
tells
you
well,
london
is
actually
1559
and
berlin
is
actually
29.
30.
yeah.
O
O
O
A
P
If
you
have
a
mic,
the
the
only
way
that
I
implemented
it
was
I
I
look
at
the
last
base
fee
for
the
block,
and
I
said
you
know
just
a
pretty
naive
fee
cap
for
the
transaction
is
two
times
the
last
base
fee
and
that
can
be
configurable
with
a
flag
to
your
guest
client
and
then
for
the
tip.
I'm
just
looking
at
what
are
the
tips
in
the
last
block
and
I
look
and
I
try
and
calculate
what
sort
of
the
average
the
median
tip
is
in
that
set.
P
Q
P
P
F
P
Q
I
personally
like:
if
we're
gonna
maintain
legacy
transactions,
we
should
probably
maintain
the
legacy
endpoint
for
them.
This
is
like
for.
I
we've
had
a
lot
of
issues
at
chainsafe
because
of
gpo
like
miscalculations
and
stuff.
Do
you
do
the
sampling,
especially
due
to
mev,
and
I
think
like
we
should
probably
just
not
with
that.
N
P
Q
Q
A
Q
The
alternative
yeah
I
mean,
but
it's
backwards,
compatible,
which
is
nice
and
also
gives
flexibility
to
to
like
you
guys,
because
you
can
have
you-
can
do
some
sort
of
flag
configuration
beforehand
to
understand
which
one
you
want
to
actually
trigger.
You
know
if
you
want
to
trigger
legacy
or
if
you
want
to
trigger
the
current
one.
The
code
changes
like
one
if
statement
and
maybe
a
flag.
Q
B
So
we
only
have
one
minute
left
and
I
just
want
to
like
hit
a
few
things
really
quick
before
we
wrap
first.
Thank
you,
everybody
for
coming
out,
whether
it's
early
or
late,
for
you
really
appreciate
it.
We've
got
a
ton
of
people,
a
ton
of
different
wallet
teams
around
the
world.
So
again,
thanks
for
coming
and
trying
to
resolve
this
stuff,
synchronously,
then
a
few
other
things.
B
So
this
wallet
cheat
sheet.
We've
mentioned
it
a
bunch
of
times.
This
is
where
we're
trying
to
gather
resources
aimed
at
people
like
you
who
are
working
on
the
interface
layer.
So
please
make
sure
to
bookmark
this
and
check
it
pretty
frequently,
because
we're
going
to
be
updating
it
with
resources
as
people,
surface
them
or
answering
questions
there.
B
The
r
d
discord
is
where
a
lot
of
this
discussion
is
being
hashed
out.
So
if
you
haven't
joined
there
already,
please
join
I'll
grab
a
link
and
put
it
there
unless
tim
has
already
done
it,
and
I
would
we'd
really
appreciate
if
people
could
engage
their
two
15
59
channels
and
that's
where
a
lot
of
this
is
happening
and
then
tim
really
quick.
Do
you
want
to
give
like?
Maybe
people
already
know
this,
but
like
the
timelines,
tentative
timelines
for
when
this
is.
A
A
Then
we
would
fork
gordy
a
week
after
that
so
june
16th,
and
then
we
would
fork
rinkavi
a
week
after
that
june.
23Rd
assume
all
that
goes
well,
and
you
know
we
don't
like
find
a
big
consensus
issue,
we're
tentatively
planning
1559
for
july
14th
on
mainnet,
but
we
want
to
see
the
first
test
net
go
well
before
we
actually
initiate
before
we
actually
set
a
block
number
for
for
mainnet
and
yeah.
A
I
it's
not
100
sure
that
clients
will
be
ready
for
the
june
9th
dates,
so
it
might
slip
like
a
week
or
two.
This
is
what
we're
going
to
be
discussing
friday,
but
you
know
if
you
want
to
be
ready
for,
like
the
most
yeah
aggressive
timeline,
then
being
ready
for
june
9th
should
be
the
the
goal
and
most
you
know
I
think
most
client
teams
have
mentioned
to
me.