►
From YouTube: All Wallet Dev Meeting 4
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
perfect
so
Welcome
to
our
wallet
dose
number
four.
We
have
a
few
things
on
the
agenda
today.
The
first,
you
know
official
item
is
the
URI
URL
working
group
updates.
A
C
Incur
with
Sam
James
your
mic
is
incredibly
broken
right
now,
if
you
go
into
Discord
settings
under
voice
and
video,
you
can
do
some
local
tests
and
see
if
you
can
figure
it
out.
B
Yeah
yeah,
okay;
no,
that
was
just
on
my
side.
Sorry,
the
yeah!
Sorry,
so
was
this
section
just
for
General
demos
or
specific
to
you
were
saying:
UI
ux,
something,
oh.
A
This
is
for
so
there's
a
separate
working
group,
that's
being
hosted
by
the
cat
herders
on
Uris
and
urls,
so
we
have
a
couple
different
proposals
that
are
being
discussed
there.
A
So
if
you've
ever
seen
like
the
ethereum
colon
pay,
Dash,
URLs
or
anything
along
those
lines
that
that's
kind
of
coming
out
of
that
working
group,
so
the
the
most
basic
one
is
just
simply
like
an
eth
colon
than
a
prefix
and
then
a
payload
and
that's
kind
of
like
the
the
family
of
URI
URLs.
And
this
is
something
that
we're
thinking
of
bringing
into
the
all-wallet
devs
call,
instead
of
keep
it
keeping
it
separately,
so
I
mean
obviously
wallets
are
going
to
have
it.
A
So
this
this
isn't
really
my
working
group
I'm
just
going
to
try
and
give
a
summary
on
it
so
yeah,
so
we
want
to
bring
it
into
the
all
wall
of
devs
called
just
to,
because
wallets
are
the
ones
that
are
probably
going
to
be
implementing
a
lot
of
these
URL
handlers,
and
there
are
quite
a
few
different
proposals
on
what
types
of
URLs
to
support.
So
one
of
them
is
like
transaction
receipts.
One
of
them
is,
you
know,
just
simply
sending
money,
so
the
eips
are
in
the
agenda.
A
If
you
guys
want
to
take
a
look
at
them
and
I.
Think
key
here
is
also
working
on
4804.
So
if
you
want
to
give
a
summary
on
on
that
particular
scheme,
please
do.
D
Sure,
absolutely
so,
I
think
a
lot
of
people
may
not
have
some
background.
I
actually
I
think
some
of
them
already
have,
but
maybe
a
lot
of
them.
You
may
not
have
their
backgrounds,
so
probably
I
can
have
a
quick
go
through
what
what
I'm
going.
Let
me
see
what
the
EIP
or
a04
is
going
to
do
so
I
need
to
wait.
I'm
trying
to
share
my
screen,
but
looks
like
this.
This.
D
A
Sure
we
can,
we
can
probably
move
this
to
actually
James
is
your
screen
sharing
working?
We
should
probably
check
that
too.
B
Right,
oh
yeah,
well,
actually,
actually
handing
over
to
Blake
who's
prepared
it.
So
we've
got
from
our
team.
We've
got
John
Jake
and
Blake
from
the
BLS
wallet
team,
I.
B
D
Okay,
I'm
back,
so
let
me
share
my
screen.
D
Can
you
see
yeah
so
I
have
a
present
this
to
the
previous
URL,
where
I
working
group,
and
so
this
is
basically
how
the
motivation.
Basically,
we
see
there's
a
great
Trend
that
a
lot
of
nfts
they
are
uploading
their
web
content
on
top
blockchain,
for
example.
D
One
example
we
saw
is
a
server
broker,
which
they
said
they
have
upload
all
the
media
data,
the
SVG
layers
on
Google
blockchain,
so
that
the
narrative
is
that
they
will
never
lose
the
media
files
so
because
it's
stored
on
on
top
of
blockchain
and
so
I
took
a
look
at
their
contract
and
see
how
they
are
able
to
achieve
that.
D
If
nobody
hosts
it
so
and
then
a
further
take
a
look
at
how
they
might
do
it,
and
then
they
have
actually
have
meta
metadata
contract,
which
basically
stores
all
the
layers
they
have
store,
and
then
they
can,
for
example,
random
any
token
ID
and
starting
from
their
offset.
That
is
from
zero,
and
then
they
will
run
in
all
the
layers,
one
by
one
and
then
so,
given
the
next
offset,
so
I
can
curve
the
next
part
and
then
so
this
just
continues.
D
Then
I
can
retrieve
all
the
SVG
components
that
they
upload
on
on
Hardware
object.
So
I
think
this
is
really
interesting
application
when
we
realize
there's
such
kind
of
like
using
students
midnights
as
their
storage
layer
to
upload
some
the
file
valuable
objects.
Another
example,
I
found
is
called
ad
blocker
I
recently
found.
They
have
also
said
that
they
have
they're,
basically
are
ft
that
upload
some
code
that
is
able
to
randomly
generate
some
pictures
according
to
their
code.
D
So
this
is
an
example,
so
they
create
a
lot
of
a
lot
of
basically
different
empty
images
by
just
using
different
random
C
but
the
same
code.
D
So
they
claim
that
they
can
they're
able
to
basically
replay
all
these
things.
These
pictures
on
top
of
ethereum.
However,
actually
we
also
double
checked
your
contract,
so
I
I
and
they
are
still
also
using
their
centralized
servers,
which,
which
is
other
block
Slash
some
token
ID,
something
to
random
those
objects,
even
though
I
can
find
their
JavaScript
on
the
on
the
e0
minutes.
D
D
So
here
is:
let
me
just
quickly
go
to
the
the
this
this
one,
so
this
is
kind
of
like
a
similar
HTTP
schemer,
but
it's
using
control
battery,
which
we
register
at
Ina,
and
it
will
tell
us
which
contract
you
want
to
call.
It
can
be
ens
or
the
20
bias,
counter
hacks
and
then
corresponding
Channel
ID,
and
then
the
master
right
method,
ID
and
corresponding
parameters
and
and
there's
a
way
how
to
process
these
parameters
in
different
types
defined
in
the
standard.
D
So
for
setup
worker
perspective,
we
basically
create
a
contract.
That
is
a
scam
that
is
at
this
location,
and
this
country
actually
is
very
straightforward.
It
just
tells
which
token
ID
that
one
to
render
and
just
repeatedly
call
the
sort
of
broadcast
contract
and
then
to
obtain
corresponding
offset
and
then
call
next
time
until
the
office
of
becomes
zero
and
concatenate
all
the
bytes,
so
that
we
can
obtain
the
final
SVG
or
ft
files
by
this
by
this
method
and
then
with
the
standard
defined.
So
we
are
able
to
render
it.
D
So
this
is
the
website
web
Suite
schema
scheme,
which
we
have
the
CNS
register
as
the
this
address,
and
then
we
call
this
method
and
provide
the
parameter
of
this
file
is
the
token
number
so
I
have
a
browser.
Here
is
a
buy
box
that
enables
this
feature
so
is
through
our
Gateway
that
influenced
by
us.
So
it
just
applied
the
the
rest
of
field.
D
Then
it
will
automatically
look
up
the
corresponding
address
and
call
the
contract
with
the
corresponding
method,
and
now
we
are
able
to
directly
render
this
contract
using
the
the
URL.
So
this
is
the
the
main
motivation
of
that.
What
the
VIP
for
a04
is
doing
so
right
now,
eip4804
is
in
the
review
stage,
and
Sam
also
gave
a
lot
of
suggestions.
D
Comments
on
how
to
be
able
to
be,
for
example,
work
with
existing
standard
and
also
some,
for
example,
how
we
are
able
to
parse
those
those
query,
Parts,
employee
and
also
argument
parts
so
that
we
are
avoid
confusion
at
the
same
time
will
be
as
close
as
HTTP.
So
right
now,
we
are
looking
for
one
or
more
reviewers
to
help
to
reveal
the
standard
so
that
you
can
be
able
to
be
more
production
ready
and
there
are
also
a
couple
of
community
members.
D
Actually,
they
are
here
he's
asking
me
whether
the
stability
of
this
standard,
so
that
they're
able
to
incorporate
those
links,
for
example,
directly
into
their
token
UI,
so
that
they
don't
need
to
worry
about
you
using
ffs
or
other
third
party,
centralized
servers
to
store
that
store
that
store
UI
so
that
you
can
retrieve
all
the
data
permanent
on
top
of
if
you're
on
blockchain.
So
this
is
the
automation,
status
and
I'm
happy
to
answer
any
questions
so.
D
A
Cool,
so
thanks
a
lot
for
giving
us
an
update
on
that
and
yeah
definitely
looking
forward
to
seeing
where
it
goes
now.
I
think
BLS
wallet
wanted
to
demo
some
new
features
and
I
think
that'd
be
kind.
F
B
Yeah
thanks,
yes,
I
was
just
saying:
we've
got
a
team
here
and
Blake's
and
John
have
recently
started
with
us,
but
yeah
the
goal
would
be
less.
What
it
is
to
yeah
provide
a
module
that
other
wallets
can
integrate
to
basically
get
transactions
on
layer
2
cheaper
than
they
already
are
by
doing
signature,
compression
and
yeah,
which
were
just
the
size
of
the
roller.
B
We've
got
a
client
module
that
we've
integrated
into
a
prototype
wallet,
which
is
just
called
quill
and
that's
what
Blake
will
be
demonstrating
so
he'll
be
using
coil
and
just
showing
some
of
the
features
that
the
smart
contracts
provide.
So
as
well
as
the
low
cost,
we've
got
multi-action
user
operations.
So
we
we're
using
the
same
terminology
as
four
three
three
seven,
but
we're
not
yet
compliant
with
4337,
as
it's
still
moving
around
and
yeah.
So
Blake.
If
you're,
ready
I
can
hand
it
over
to
you,
foreign.
E
Excuse
me:
I,
actually
went
ahead
and
created
a
video
of
this,
so
I
didn't
have
to
worry
about
a
live
demo,
so
I
will
go
ahead
and
start
the
video,
and
if
anybody
has
any
issues
hearing,
let
me
know
and
I'll
get
that
fixed.
E
A
C
C
F
B
Yeah
just
to
filler.
In
the
meantime,
yeah
we've
been
reaching
out
to
a
few
wallets
over
time.
We've
just
had
the
contractor
audited.
We've
got
some
fixes
to
put
in
and
then
yeah
once
we're
in
mainnet.
B
We
will
just
sort
of
go
back
hit
up
the
wallet
so
we're
interested
and
and
reach
out
to
some
more
layer
twos
as
well,
because
we
have
to
deploy
the
contracts
on
well,
we're
going
to
be
deploying
them
to
optimism
and
arbitrim
first
and
then
yeah
other
layer,
twos
that
have
approached
us
as
well
for
their
own
chains.
B
So
the
yeah,
basically
you've
got
a
verification
contract
that
is
basically
a
wallet
Factory
and
that
will
create
these
wallets.
Those
wallets
trust
the
Gateway,
which
is
why
we
had
those
that
code
audited
to
call
function,
generically
call
functions
through
the
wallet
and
so
that
Gateway
will
check
a
bundle
of
user
operations.
Each
user
operation
is
signed
by
a
BLS
key
held
in
the
client
wallet
and
the
aggregator,
which
eventually
will
be
integrated
into
l2s
yeah
Aggregates
the
signatures
together
and
then
that
bundle
is
simple
too.
B
Oh
you're
gonna
get
the
feedback
yeah
so
that
bundle's
sent
to
the
verification
Gateway
contract,
which
then
performs
each
user
operation
via
each
wallet
that
one
key
feature
as
well,
which
I
don't
think
is
in
the
demo,
is
that
adapt
can
sponsor
transactions.
So
it's
basically
gasless
transactions
without
Sorry
by
actually
coming
from
the
wallet
address
as
well,
which
I
think
with.
B
If
I'm
not
mistaken
there,
the
the
GSN
way
of
doing
it,
I
think
is
via
signed
messages,
and
so
the
address
isn't
necessarily
the
wallet
for
how
it
currently
works,
but
maybe
for
it's
different
for
4337,
but
yeah.
If,
like
yeah
like,
if
you're
ready,
did
you
want
to
try
again.
E
Yeah
yeah
I
think
so
I
can
try
one
more
time
just
without
my
headphones
on
and
the
sound
coming
through.
My
laptop
turns
out.
I
have
to
install
additional
software
to
be
able
to
record
the
audio
so
yeah.
Hopefully
this
works
and,
if
not
I,
might
need
to
try
to
install
a
software
real,
quick,
a
quick
demo
of
the
browser
extension
that
we're
working
on
hey
everyone.
My
name
is
Blake
I'm
with
the
BLS
law
team.
Don't
forget
to.
B
A
E
All
right,
hopefully,
it
works
this
time,
hey
everyone.
My
name
is
Blake
I'm
with
the
BLS
law
team
of
the
privacy
and
scaling
Explorations
group
within
the
ethereum
foundation,
I'm
here,
to
give
a
quick
demo
of
the
browser
extension
that
we
were
working
on,
that
we
call
quill,
yeah
I'll,
go
ahead
and
sign
right
in
I
already
have
loaded
up
the
onboarding
screen
for
the
extension
wallet
and
I'm
going
to
go
ahead
and
complete,
creating
my
account.
It's
a
first
step.
I
need
to
set
a
password.
E
And
then,
finally,
you
have
the
ability
to
view
your
secret
phrase,
review
it
and
then
confirm
it.
It
is
worth
noting
that
this
is
an
extension
that
is
really
just
meant
for
demonstration
purposes
and
not
meant
to
be
used
with
Mania
mainnet,
which
is
why
we
have
made
it
easy
for
everyone
and
just
displayed
the
words
that
you
need
to
input.
E
Oh
I'll
go
ahead
and
confirm
the
secret
phrase
and,
as
you
can
see,
this
brings
me
to
a
page
here
with
a
smart
contract
wallet
that
was
generated.
I
have
the
ability
to
add
multiple
smart
contract
wallets
within
the
quill
extension
and
then
on
the
right
side
of
the
screen.
We
have
a
few
tabs
that
are
related
to
the
selected
wallet
right
now.
I
just
have
this
transactions
tab
selected,
which
will
eventually
show
the
list
of
transactions
that
have
been
executed.
E
The
first
thing
I
want
to
demonstrate,
while
within
the
quill
extension,
is
just
sending
ether
from
one
wallet
to
another,
so
I'm
going
to
do
that
and
send
some
ether
from
wallet
0
to
wallet
one
but
I
need
to
fund
it.
First,
so
I'm
going
to
go
over
to
metamask
and
send
some
ether
to
wallet,
zero.
E
E
E
This
this
brings
up
a
transaction
request:
modal,
that
I
can
go
ahead
and
confirm
the
transaction.
E
E
So
a
little
bit
of
the
functionality
within
the
quill
extension
next
up
I
do
want
to
demonstrate
a
simple
application
that
integrates
the
quilix.
The
quill
wallet
so
I'll
take
us
over
to
this
other
tab
where
we
have
this
demo
application
that
interacts
with
an
erc20
contracts
on
the
left.
Here
we
have
a
component
that
is
linked
up
to
your
wallet.
E
Basically,
you
could
mint
10
tokens
and
approve
them
and
then
on
the
right.
We
have
the
component
that
is
linked
up
to
a
spender
contract
that
has
the
ability
to
call
transfer
from
and
transfer
the
tokens
from
your
wallet
over
to
the
spender
smart
contract
wallet
so
yeah
to
demonstrate
it.
I'll
go
ahead
and
connect,
and,
as
you
can
see
here
is
the
address
that
I
generated
in
the
quill
extension
and
the
remaining
90
each
that
I
have
in
that
wallet,
I'm
going
to
go
ahead
and
mince
10
tokens.
E
Finally,
I
wanted
to
demonstrate
this
bundle
up
button
at
the
bottom.
This
is
what
we're
most
proud
of,
because
most
wallets
have
the
functionality
to
do
what
I
just
demonstrated,
how
mints,
prove
and
pull
tokens,
but
what's
unique
about
our
wallet,
is
that
we
have
the
ability
to
bundle
up
a
group
of
transactions
and
send
them
as
one
request
so
by
clicking
this
button
it'll
first,
do
this
mint
then
approve,
then
pull
all
part
as
all
as
one
of
one
transaction.
So
do
this.
E
E
Great
you
can
see
that
I
did
all
three
of
those
as
one
and
incremented
the
spender
from
90
to
100.,
and
we
go
back
to
the
quill
extension.
We
could
see
all
the
transactions
now
showing
up
related
to
wallet
zero
and
we
have
this
nice
new
modal
that
was
implemented,
that
we
can
click
here
and
see
the
actual
actions
that
were
included
in
each
of
the
transactions.
So
you
could
see
the
mints
approved
and
the
contract
interaction
here,
close
that
and
the
last
thing
that
I
wanted
to
show.
E
Everybody
is
the
actual
code
that
we
use
to
group
those
transactions
together.
This
right
here
is
the
bundle
up
function
that
gets
called
when
you
click
the
button.
At
the
bottom
of
the
screen,
pretty
straightforward,
you
can
see
the
three
different
transactions,
the
mint
approve
and
pull
transaction
here,
they're
all
just
using
the
erc20
object
to
connect
the
signer
and
then
populate
the
transaction,
but
instead
of
doing
each
of
those
individually,
we
are
actually
sending
them
using
window.etherium.request
and
the
send
transaction
method.
E
And
then
we
pass
all
three
of
the
transactions
in
an
array
as
part
of
the
params
of
a
key.
It
is
important
to
note
that
this
isn't
the
typical
spec
for
each
send
transaction.
E
Excuse
me,
our
custom
RPC
Handler
actually
intercepts
the
send
transaction
function
and
overwrites
it
with
a
function
that
understands
the
multiple
transactions
that
are
passed
in
aspiram's
key
of
the
object
that
is
sent
and
then
yeah
last
up
we're
just
waiting
on
the
get
transaction
receipt
to
show
on
the
updated
information
to
the
user.
E
E
B
E
Yeah,
that's
a
it's
a
good
question,
I'm,
actually
relatively
new
to
the
team,
I'm,
not
sure
if
anyone
else
in
the
call
would
be
able
to
jump
in
for
that.
One.
B
Yeah
Jake,
were
you
talking
with
kotok
about
that
I
think
you
might
more
across.
G
That
section
considered
just
like
a
separate
RPC
I
think
for
I.
Don't
actually
remember
the
exact
Sun.
Why?
But
since
that
is
an
array,
and
normally
the
sentreen's
eye
uses
the
first
argument
inside
of
that
logical,
extend
to
add
additional
transactions,
we
could
use
a
custom
method.
We
need
to
do
that
really
with
the
way
the
wall
is
working
now
good
work
like
just
a
general
transaction
or
if
you
wanted
to
pass
more
exactly
that,
is
that
generally
more,
like
a
custom
method
from
the
RP
plug
that.
C
I
think
I
got
your
question
you're
cutting
in
and
out
a
lot
So
when
you
say
you
send
it
as
an
array
you're
saying
that
each
of
those
transactions
is
a
different
parameter
in
the
Json
RPC
requests
like
in
the
params
array,
each
one
separately.
It's
not
an
array
inside
of
an
array.
G
Correct
just
gonna
be
I,
think
the
normal
spec
and
sorry,
if
I'm
kind
of
is
basically
just
remember
through
the
spec
for
that
yeah
I
think
it's
normally
one
item
Ray
and
that's
the
normal
Lux
and
transaction
format.
So
that
window
is
here,
but
we
basically
so
we
actually
look
at
on
that
first
parameter
and
we'll
also
include
those
if
they're
valid,
related
transactions.
C
Okay,
so
a
separate
question,
then
I
think
that's
probably
fine
I'm
a
little
bit
concerned
just
so
depending
on
the
whoever's
on
the
other
end,
are
implementing
the
other
end
of
that
when
you
deserialize
the
transaction,
this
realization
becomes
much
more
complicated
if
you
have
to
just
realize
that
Union
versus
the
serializing,
just
a
single
known
shape,
this
isn't
insurmountable
and
I.
Think
a
lot
of
things
already
have
mechanisms
for
dealing
with
this,
but
it
does
add
complexity.
C
So
it's
like
in
mud.
Second
question,
though,
is
Json
and
RPC
I
believe
the
ethereum
Json
RPC
supports
batching
at
the
Json
RPC
level
layer
and
so
I'm
wondering
why
you
chose
to
go
this
route
instead
of
just
doing
a
Json
RPC
batch.
B
Yeah
the
the
difference
there
is
because
we
are
aggregating
the
signatures
like
we
need
to
get
all
the
transactions
as
one
bundle
yeah,
and
so
that's
a
different
yeah.
That's
sort
of
why
we're
doing
it.
A
B
B
F
You
understand
correctly,
actually
the
demo
doesn't
show
the
real
flow.
The
real
flow
is
how
to
get
multiple
transactions
probably
sent
by
different
users
into
a
single
bundle
and
the
instant
bundle
up
to
bundle
them,
not
the
client
application
in
the
UI.
There
are
other
ways:
Cloud
applications
and
multiple
application.
A
batch
of
requests.
B
Yeah
I
know
that
that
I
think
on
the
example
dap
there.
The
term
bundle
up,
maybe
isn't
ideal,
so
bundles
are
yeah,
definitely
multiple
wallets
signing
user
operations
and
sending
it
to
an
aggregator
or
an
L2
that
supports
aggregation
and
they'll
bundle.
Multiple
different
wallets
as
user
operations
together
in
that
demo,
that's
just
a
the
multi-actions
within
a
user
operation,
and
so
that's
a
single
transaction.
Sorry,
a
single
user
operation
with
multiple
actions
and
that's
something
like
a
ux
benefit
for
dapps.
B
B
No
in
that
example,
like
the
user
flow,
without
that
would
be
you
go
to
an
exchange
and
you
have
to
you
know,
approve
the
DAP
all
of
your
X
token,
whatever
it
is,
and
then
after
you've
approved,
adapt
that
token,
then
you
can
do
a
swap,
and
then
you
trust
the
DAP
to
to
do
your
other
actions
and
you're
signing
those
other
transactions.
So
you're
signing
an
approval.
B
A
blanket
approve
all
of
your
token,
which
is
not
a
great
practice
and
then
doing
an
interaction
like
moving
a
token
or
if
daps
want
to
be
more
secure,
but
then
worse
ux
would
be
before
every
interaction
you
need
to
approve
that
amount
and
then
do
that
amount.
You
know
say
a
swap
or
something.
This
was
just
to
show.
That
example
that
if
that
dap
does
need
to
approve
an
amount
and
then
move
that
amount,
it
can
do
it
atomically
as
one
so
either.
B
D
B
Yeah
so
so
yeah.
This
was
started
on
this
before,
like
some
yeah
a
little
moment
before
4357
was
written
about.
But
yes,
our
V2
will
hope
to
make
more
in
line
with
43q7
and
the
goal
of
the
original
project
was
about
reducing
transaction
costs.
So
it
was
focused
on
L2
deployment,
only
not
not
necessarily
L1,
whereas
I
think
4337
is
more
about
yeah,
focusing
on
the
more
generic
signing
mechanism,
whereas
ours
was
to
say
specifically
use
BLS
to
save
transaction
costs
on
evm
roll-ups,
but
yeah.
C
Does
your
wallet
support
the
daps,
sending
three
separate
transactions,
but
the
user
choosing
to
batch
them?
It's
like
these
are
just
doesn't
sign
individually.
They
just
wait
until
all
three
have
been
clicked,
then
they
sign.
B
I
I,
don't
know
if
that's
in
our
prototype,
yes,
but
the
client
module
does
permit
that
yeah
yeah,
so
yeah.
The
idea
is
the
client
module
will
have
all
the
functionality
and
yeah
there
can
be
local,
bundling.
B
Yeah
I
guess
you
could
do
it
either
way
like
either
you
put
three
actions
within
one
Atomic
user
operation
or
you
could
have
three
individual
user
operations
that
are
sent,
but
sorry,
no
I,
think
sorry.
Your
question
was
more
so
around
does
the
can
the
user
of
the
of
their
own
interactions
take
three
separate
transactions
and
then
choose
to
sign
them
as
one
action
as
one
user
operation?
Is
it
correct,
yeah,
yeah.
C
Like
I'm,
using
adapt
and
I'm
gonna
go
do
three
or
four
different
things:
for
example,
ens,
maybe
I
want
to
you
know
edit
the
owner
and,
at
the
same
time,
I
want
to
update
an
ipfs
hash
or
something
there's
no
need
for
me
to
do
those
as
two
separate
operations.
I
can
just
do
them.
You
know,
there's
no,
no
reason
that
I
need
to
send
them
separately.
C
B
Yeah
in
the
in
the
web,
through
World
Discord,
we've
created
a
separate
channel
for
design,
and
we
had
a
kind
of
a
good
review
of
the
ux
to
say:
look
what
what
might
wallets
want
in
the
future.
Multi-Chain
multi-action
blah
blah
and
one
of
the
things
was
something
like
an
outbox
where
you
could
potentially
queue
up
a
few.
We
haven't
implemented
everything
in
this
design.
B
It
was
more
of
a
you
know
what
what
could
wallets
look
like
and
then
the
Prototype
is
just
more
so
to
show
the
integration
of
the
client
but
yeah
an
outbox
concept
was
was
designed,
but
we
haven't
implemented
that
at
least
I
don't
think
we
have
handshake
interview
correctly.
I,
don't
think
we've
gotten
that
far.
Yet
we
had
it
on
the
card.
So
then
we
maybe
pushed
it
back.
Yeah.
G
There's
also
some
like,
usually
when
the
Diaz
call
into
like,
like
a
constants
response
at
some
point
like
it
approach
the
Trinity
up,
there
can
be,
patients
would
like,
oh,
that
the
apps
all
those
up
and
trying
those.
So
we
have
this
little
bit,
but
with
there.
G
The
other
thing
that's
important
to
note
is
that
transaction
we're
getting
actually
through
our
aggregates.
It's
actually
look
at
the
bundle
used
and
then
it
will
hopefully
returns
like
transaction
hash.
That
is
a.
G
In
other
cases,
you
the
L2
transaction,
any
bundles
from
many
and
so
there's
digital
proxy.
We
have
to
do
to
pass
that
through
so
so
there's
some
more
complications
tracking
all
that
stuff
from
a
court
perspective
with
that
as
well.
At
checkout.
B
C
G
I'll
just
I'll
rejoin,
but
yeah
yeah,
there's
some
complications
to
stacking.
Although
from
what
we've
looked
at.
B
A
Awesome
thanks
a
ton
for
putting
that
together
and
that's
really
exciting
to
see
it
coming
together.
Now,
what
are
we
going
to
see
this
on
mainnet.
B
Yeah
no
good
question:
we
have
the
yeah
the
audit
back
and
I'm
just
going
through
the
issues
one
by
one,
so
yeah
I
don't
want
to
give
an
S
to
it,
but
yeah
so
yeah.
What
would
be
the
point
to
mean
that
where
are
we
now
August?
Let's
say
after
the
merge
how's
that.
A
A
Cool,
so
if
nobody
else
has
anything
they'd
like
to
demo,
then
I
guess
we
can
go
back
to
talking
about
the
extension
registry
and
other
topics
that
aren't
necessarily
on
the
agenda.
A
A
Yeah
so
where
we
leave
off,
we
were
talking
about
chaining
wallets
together.
A
So
my
thought
on
that
is,
it
really
seems
like
all
of
those.
So
if
we
imagine
like
a
line
between
the
application
and
the
wallet
right,
all
of
the
chaining
and
connection
stuff
is
on
one
side.
The
wallet
side,
whereas,
like
you
know,
and
the
DAP
needs
to
know
nothing
about
it
and
doesn't
care
about
it.
So
I
really
don't
think
the
URL
connection
scheme
needs
to
care
at
all
about
how
the
chaining
is
implemented,
because
that's
completely
different,
like
that's,
opaque
to
the
dab.
C
C
Sure
so
so
the
adapt
when
it
connects
to
something
would
maybe
let's
say,
connect
with
the
well
with
the
scheme
right.
So
while
it
go
on
slash,
slash
whatever
here's,
my
here's,
how
to
get
a
hold
of
me
opens
up
a
server
whatever
that
means,
and
then
something
receives
that
and
connects
you're
saying
that
that
something
then.
C
I
see
what
you're
saying
I
think
the
thing
that
they
keep
swapping
back
up
into
my
head
is
I.
I
I
feel
like
we
shouldn't
be
leaking
to
any
of
these
participants
that
the
other
participants
exist
even
so,
like
as
an
example,
you
can
imagine,
there's
some
very
popular
wallet
out
there
that
currently
does
signing,
and
it
also
does
some
other
things.
It
has
some
other
features
right,
like
maybe
it
offers
user
swaps
right
in
the
wallet.
C
Whereas
if
we
can
keep
that
information
hidden
somehow,
then
people
can't
leverage
it
now.
The
reason
I
bring
this
up
in
response
to
your
questions,
because
it
is
not
clear
to
me
how
we
can
avoid
that
sort
of
data
leaking
without
having
with
that
decision
be
made
somewhere
in
that
initial
interaction,
where
the
user
is
choosing
their
wallet
like
when
that
user
gets,
that
wallet
prompt
and
they
need
to
select
their
wallets
like
whatever
that
means
I
feel
like
that
is
the
right
time
to
make
that
choice
and
have
the
user.
A
H
Can
you
provide
a
little
more
color
on
like
what
specific
privacy
issues
you
see
with?
Okay,
we're
talking
about
a
theoretical,
Fox
swap
feature
and
an
imaginary
wallet
and
you're,
saying
that
potentially
there
could
be
something
in
between
sort
of
their
integrated
application
layer
and
then
the
core
key
management
and
signing
what.
C
Yeah,
so
the
general
idea
here
is
that
when
a
user
wants
to
interact
with
ethereum
there's
the
DAP
that
they're
interacting
with
right
and
then
there
is
some
tool
that
maybe
offers
some
protection
from
scams
like
it'll
tell
it'll.
If
you
try
to
send
a
transaction
to
a
known,
scammer
address,
it
will
pop
up
and
say:
hey,
don't
do!
This
is
a
very
bad
idea,
maybe
there's
another
tool
that
is
again
in
that
flow.
C
That
does
really
good
visualizations,
and
so,
when
it
sees
you
trying
to
do
a
transaction,
it
can
display
that
or
present
it
in
a
way
that
really
makes
sense
to
the
user
and
then
there's
the
tool
that
does
the
actual
sign-in
right.
The
idea
here
is
is
that
we
don't
necessarily
want
the
people
who
are
really
good
at
Key
Management,
to
also
be
the
ones
that
need
to
build
a
visualizer
and
need
to
build
scan
protection
like
those
are
three
very
different
tasks.
C
We
want
to
be
able
to
delegate
them
to
teams
that
are
good
at
those
individual
tasks
and
ideally
products
and
have
a
product
competition
that
doesn't
bundle
them
all
together.
So
you
don't
you
shouldn't,
have
to
choose
the
wallet
that
does
all
three
of
those
things
good
enough.
You'd
ideally
choose
three
wallets
one
that
each
does
their
respective
thing
very,
very
well,
and
so,
if
we
we
have
this
kind
of
these
multiple
tools
in
the
chain
between
the
Dapper
question.
C
To
do
something,
and
you
finally
eventually
sign
it
and
that
last
tool
may
be
like
a
hardware
wallet
or
something
I.
Don't
know
we
need
a
way
for
them
to
to
communicate
between
each
other.
So
you
need
to
be
able
to
pass
the
transaction
first
to
the
first
one
like
the
scammed
Checker
and
then
pass
it
to
the
visualizer
and
then
pass
it
to
the
signer.
C
And
ideally
you
want
to
do
that
in
a
way
that
doesn't
leak
privacy
of
the
user,
like
in
in
a
way
that
the
none
of
the
pieces
involved
know
exactly
what
the
other
piece
is
involve.
So
the
scam
detector
doesn't
know
that
you're
using
metamask
or
rainbow
wallet
or
something
else
like
they
just
know.
I'm,
detecting
scams
and
I
pass
it
along
and
the
visualizer
doesn't
know
that
you're
using
the
scan
detector
and
they
don't
know
that
you're
using
metamask,
and
they
do
because
they
just
pass
it
along.
H
So
I
I
think
one
issue
there,
even
if
you're
pushing
for
standards
for
modularity
that
all
wallets
can
you
know,
use
these
things,
maybe
something
like
almost
like
snaps
the
the
problem
is
I
think
more
externalities
in
that
you
know.
Why
do
we
see
software
wallets,
bundling
and
features?
Well,
it's
differentiation
and
it's
a
way
to
monetize
wallet
development
in
particular
with
metamask
and
swaps.
H
H
C
So
I
think
that
you
what
you
said
it
makes
sense,
and
it's
a
very
valid
point:
I
think
that
the
incentives
aren't
there,
and
this
is
part
of
why
I
think
that
the
Privacy
is
is
important,
because
what
I
worry
about
is,
if
you
know
wallets,
are
incentivized
to
provide
that
One-Stop
shop,
because
that
One-Stop
Shopkins
include
add-on
services
like
upsells
right
like
exactly.
C
And
so
whatever
we
come
up
with
I
think
if
we,
what
we
want
to
maximize
users
ability
to
have
this
choice
of
modularity,
it
needs
to
be
done
in
a
way
that
the
individual
tools
can't
know
what
other
tools
the
user
is
using
and
the
individual
tools
can't
prevent
the
user
from
using
other
tools
so
like
it
needs
to
be
designed
such
that
the
user
or
the
wallet
doesn't
need
to
get.
We
don't
need
to
get
buy-in
from
the
wallets
like
either
the
wallet
works
with
the
we
do.
C
Any
biofin
adapts
because
adapts
will
need
to
communicate
this
new
mechanism,
but
we
wouldn't
need
buy-in
from
the
wallets,
because
the
walls
you
don't
need
to
work
with
adapts,
if
that
makes
sense.
A
A
If
we're
taking
that
position,
then
I
think
chaining
is
the
wrong
like
visualization
or
analog
for
it,
because
chaining
is
very
permissive.
Each
wallet
would
be
able
to
control
which
data
is
passed
on
to
the
next
wallet.
I
think
what
you'd
want
to
do
is
think
about
it
from
like
an
orchestrator
or
like
a
router
point
of
view,
or
you
have
something
that
sits
atop
all
of
the
routers
and
passes
requests
like.
A
First,
it
passes
the
request
to
the
the
scam,
the
the
scam
detector,
and
then
then
it
receives
a
response
from
the
scam
detector
decides
what
to
do
and
then
then
goes
to
the
visualizer
and
gets
the
response
decides
what
to
do
what
to
do,
and
so
it
goes
back
and
forth
to
this
orchestrator
that
sits
on
top
of
all
of
the
of
the
wallets.
That
way.
There's
no
cooperation
from
the
wall.
That's
required.
C
Yes,
so
I
can
definitely
see
an
orchestrator
potentially
being
the
solution
here,
I'm
going
to
contend
a
little
bit
that
that's
required.
I
think
that
the
only
so
we
know
that
the
signer
has
to
be
at
the
end
of
the
chain,
all
right,
I,
don't
think
it
makes
sense
for
the
signers
to
not
be
at
the
end
of
the
chain.
C
A
So
there
are
things
that
happen
after
signing
right,
like
I.
Remember
there
being
like
services
that
will
send
a
transaction
like
publish
it
at
a
certain
time
for
you,
so
that
would
happen
after
signing.
C
Sure
so,
like
the
user
does
need
to
semi-trust
each
of
the
these
tools,
they
don't
need
to
trust
the
they
need
to
trust
the
signing
tool
the
most,
because
that's
one,
has
a
private
Keys,
the
other
tools
they
do
need
like
if
they're
malicious.
Those
other
tools
are,
you
know,
give
them
bad
data
that
is
very
possible
and
there's
nothing
that
prevents
that.
H
Yeah,
it's
the
whole
Hue
carp
attack,
Vector,
where
you
know,
if
you're
relying
on
your
tool
to
to
verify
in
a
general
competing
environment,
you
know
precisely
what
you're
signing
yeah
there's
that
degree
of
trust
involved,
no
matter
what.
C
And
I
think
having
these
these
modular
components
can
help
a
lot
with
that,
because
a
particular
paranoid
user
may
actually
install
you
know
three
different
visualizers,
and
so
they
would
verify
that
each
visualizer
shows
them
the
same
thing
in
their
own.
You
know
UI
or
whatever,
and
so
that
way
by
the
time
it
gets
to
the
signer.
C
But
now
you
need
to
compromise
metamask
keys
and
you
need
to
compromise
like
four
other
visualizing
tools:
Keys,
that's
now
all
of
a
sudden,
much
harder
and
something
from
a
security
standpoint
having
you
know
allowing
all
these
tools
in
there
really
helps
you
protect
users
significantly
again,
because
they
can
verify
verify
verify
over
and
over
and
over
again
so
same
way.
Ideally,
users,
are
you
know
when
they're
using
metamask,
you
check
metamask
to
see,
does
the
transaction
look
right
and
then
you
double
check
it
again
when
it
gets
to
your
Ledger?
H
One
thing
and
I
know
I'm
just
kind
of
throwing
spaghetti
at
the
wall
here,
but
I
liked
something.
You
said
there
where
it
could
almost
be
something
with
this
system
that
verifies
the
provenance
of
like
the
data
source
for
each
plug-in
like
this,
and
actually
you
know,
would
advise
you
to
to
rely
on
like
multiple
data
sources
to
to
bet
the
the
signing
request.
C
Yeah
I
think
if
we
went
with
Sam's
router
thing,
we
could
maybe
achieve
something
like
that
where
the
router
could
say
hey,
we
noticed
you
only
have
one
visualization
tool
installed.
We
generally
recommend
you
install.
You
know
at
least
two
from
different
sources.
Here's
some
recommendations,
just
to
kind
of
incur
help
encourage
users
to
you,
know,
follow
better
security
practices
and
that
router
tool
wouldn't
have
to
actually
implement
this
visualization
stuff
at
all.
A
C
Yeah
I
think
if
we
do
the
router
thing,
I
think
you
are
largely
correct
and
I'm
I'm
starting
to
come
around.
Just
the
more
I
think
about
it.
I
think
the
having
a
single
router,
that
is,
your
wallet
from
the
point
of
view,
is
adapt
and
when
you
get
the
pop-up,
the
router
wallet
is
what's
selected.
I
think
it's
not
unreasonable
and
one
can
imagine
a
future
where
the
browser
functions
as
the
router
right.
A
H
C
Yeah
I'll
chew
on
the
the
router
thing,
I
generally
like
the
idea,
and
it
allows
us
I
I
have
I
do
like
the
the
scheme,
selector
that
Sam's
been
typing
about,
and
so
this
would
allow
us
to
keep
this
game
selector
and
not
break
anything,
and
it
simplifies
integration
with
depths,
because
the
apps
don't
need
to
worry
about
anything.
A
sort
of
complex
modularity
system.
They
just
are
like
hey
I
need
a
transaction
to
be
sign
of
set.
A
C
C
A
That's
the
RPC
provider
list
proposal.
C
The
Json
schema
it's,
the
HTTP
vehicle
schema
I'm,
giving
a
hard
time.
A
A
So
on
the
web
3
well
repository
there
or
organization
on
GitHub.
There
is
an
implementation
of
this
that
can
merge
lists
and
do
all
the
fanciness
that
is
specified
I,
don't
know
how
wallets
do
like
libraries
like?
Would
you
grab
a
common
implementation
for
this
for
all
wallets?
Would
you
all
implement
it
yourselves,
so
I'm
curious
about
that.