►
From YouTube: Account Abstraction: Making Accounts Smarter
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/6/account-abstraction-making-accounts-smarter/index
This talk discusses the limitations of externally owned accounts (EOAs), use cases for account abstraction, and how to join the account abstraction revolution.
Speaker(s): Liraz, Dror Tirosh
Skill level: Beginner
Track: Developer Infrastructure
Keywords: Account Abstraction,ERC 4337,Developer infrastructure
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
Gas
station
network,
but
recently
we're
working
with
your
Weiss,
which
was
supposed
to
pass
this
presentation,
but
he's
sick
in
the
hotel.
So
we
are
covering
him
up,
we'll
talk
about
account,
obstruction
and
the
what
can
be
done
with
it.
First,
what
is
account
obstruction,
but
before
we
talk
about
his
account
obstruction,
what
is
an
account
on
ethereum
account
comes
in
two
flavors.
One
of
them
is
externally
on
account,
but
we
all
know
in
the
other,
are
contract
based
accounts
and
if
you
have
a
wallet
you're,
probably
using
an
UI
account.
A
Ui
accounts
are
very
easy
to
start
to
work
with,
but
they
have
quite
a
few
limitations.
First
of
all,
key
management
is
very,
very
problematic.
The
private
key
is
tightly
coupled
with
the
address,
which
means
you
can
change
it.
You
have
to
keep
it
secret,
because
if
you
lose
it,
you
lose
everything,
but
if
you
make
copies
in
order
not
to
lose
it,
someone
can
find
it
and
then
he
will
get
everything
and
you
will
lose
everything.
So
Key
Management
is
hard.
A
There's
also
there's
one
one
fits
all
access
control.
You
can
do
everything.
It
might
be
good
for
you
for
personal
usage,
that
you
can
do
everything,
but
it
is
very,
very
limiting
if
you
know
a
all
these
operations
by
abstracting
them
away.
We
mean
it
is
not
the
node
that
performed
operation
that
checks
the
signature
that
checks
the
the
security
of
the
node
check,
the
balance
perform
the
payment,
but
we
abstract
it
away
and
make
a
contract
the
wallet
contract
being
responsible
for
all
of
these.
A
B
A
lot
of
things
become
easier,
but
just
the
easiest
way
to
think
about
this
is
making
contracts
while
contracts
first
class
citizens
they're
no
longer
second-class
citizens
of
ethereum,
and
that
you
don't
need
an
eoa.
In
order
to
operate
your
contract
wallet
right,
you
can
start
from
a
contract,
wallet
and
you'll
never
need
to
have
an
eoa.
A
Okay
from
now,
when
we're
talking
about
the
contextraction,
now
we're
talking
what
can
be
done
with
it
now
with
the
next
slide,
with
all
the
features
none
of
them
are
implemented
by
us,
they
are
about
to
be
implemented
by
you.
We
only
open
the
door
with
accounts
in
order
to
be
able
to
add
all
these
cool
features.
A
So
the
first
use
case
is
recovery
right
now
the
recovery
sucks.
You
can't
recap
your
private
key.
You
can't
really
recover
it.
You
have
to
save
this
private
key
somewhere
as
a
multiple
funny
words
or
otherwise,
with
account
obstruction.
You
can
Implement
into
your
wallet
social
recovery
or
other
recovery
mechanism,
and
you
can
add
a
Deadman
switch
like
if
I'm,
unfortunately
or
someone
is
about
died,
and
you
don't
want
everyone
to
lose
all
the
the
assets
he
has.
It
can
set
a
Deadman
switch.
A
A
Yes,
we're
talking
about
recovery,
but
multisig.
Of
course,
when
you're
talking
about
a
signature
cases,
multisig
is
a
something
that
we
see
we
want
to
have
for
accounts.
Another
option
is
per
device
Keys,
you
might
want
your
phone.
Your
phone
is
a
very
strong
Hardware
to
protect
keys.
So
it
might
be
very
easy
that
you
know
the
protection
of
your
phone,
whether
it's
fingerprint
or
whatever
or
other
biometric
check.
This
is
the
way
to
control
your
account
and
if
you
lose
this
device,
yes,
we
have
recovery,
we
use
another
I
will
assign
another
device.
A
A
So
it's
an
extension
that
can
be
added
on
top
of
account
obstruction
on
those
Networks
to
reduce
the
gas
fees.
And
if
you
are
looking
into
the
future,
we
know
that
ecdsa
signatures
sometime
in
the
future
will
become
weaker.
That
is,
the
attack
will
become
stronger
and
with
the
quantum
machines
eventually
within
5,
10
or
20
years,
they
will
be
able
to
be
cracked.
We
want
to
be
able
to
upgrade
our
accounts,
at
least
our
important
ones
before
them.
A
Quantum
resistant
signatures
might
be
a
way
and
again,
each
of
those
cool
features
we
are
talking
is
not
a
systematic
change
of
all
accounts
is
a
specific
account,
want
to
experiment
or
want
to
add
a
feature.
Okay,
you
upgrade
your
account,
and
now
you
have
those
features
like
any
of
those
on
the
slides
around.
A
A
Dismiss
anyone?
Okay,
now
we're
talking
about
some
roles.
You
know
you
have
right
now,
as
I
said
with
EOS,
you
have
a
signature
and
you
can
do
everything
when
you
use
Smart
account,
you
can
put
roles,
you
can
allow
different
roles
to
do
different
things.
Maybe
on
your
home
on
your
personal
account,
you
want
to
do
the
master
to
do
it
all,
but
if
it's
a
corporate
account,
you
might
say
that
you
want
the
legal
department
to
be
able
to
vote
but
not
move
tokens.
A
A
Sorry,
okay,
we
talked
about
the
the
high
end
of
a
account
that
is
accounts
corporate
account.
There
is
also
the
lower
end.
You
know
you
have
your
personal
account,
but
you
also
want
to
play
games
with
games.
Even
the
single
accept
per
request
might
be
annoying.
You
don't
want
to
accept
each
operation
so
for
games.
You
might
assign
your
account
a
session
key.
This
key
is
allowed
to
make
transaction
for
specific,
Target
specific
game.
And
now
you
are
Wallet
free.
You
free
the
ux
from
accepting
each
transaction,
and
you
know
it
is
limited.
A
A
Is
this
the
next?
Yes,
okay,
we
talked
about
the
security
about
the
role
access.
Now,
let's
talk
about
the
gas
gas
obstruction
with
normal
accounts,
the
account
has
to
have
if,
in
order
to
pay
for
the
transaction,
with
account
obstruction,
we
want
to
abstract
away
the
gas
we
want
to
be
able
for
a
third
party
to
pay
for
a
transaction
which
is
very,
very
good
for
onboarding
like
adapt,
want
to
pay
for
transaction
for
is
deployment
of
each
client
or
client
that
uses
its
own
account.
A
A
So,
paying
with
token
is
a
cool
use
case
that
we
really
want
to
have
a
in
in
the
system,
a
privacy,
if
you
think
about
it,
if
you
go
and
you
want
to
protect
this
privacy
and
use
a
mixer
like
to
another
cache
or
other,
and
yes,
you
put
the
money
in
now.
We
want
to
get
the
money
out,
but
you
have
to
have
gas
in
order
to
withdraw
this
amount.
How
did
you
get
that
gas
from
some
kyc
account
so
you're,
not
really
Anonymous?
A
B
Well,
one
thing
quick
to
add
is
the
gas
sponsorship
model
is
very
flexible.
Toll
gave
an
example
of
onboarding
where
you're
subsidizing
the
fee
entirely,
but
you
can
have
arbitrary
logic.
It's
implemented
by
a
contract.
You
can
limit
that
in
any
way
you
want
you
can
subsidize.
If
you
want
only
some
transactions
you
can
make
a
user
is
authenticate
in
some
way.
You
can
decide
only
to
subsidize
governance
actions,
I
mean
it's
arbitrary
logic,
so
anything
you
want.
You
can
do
with
this.
Just
you
decide
what
the
conditions
are,
including
asking
for
repayment.
A
As
I
said,
all
of
these
are
features
that
you
have
to
implement.
We
implement
the
infrastructure,
I'm
only
suggesting
a
cross
chain
operation
a
since
we
are
abstracting
as
we
have
a
contract.
You
have
a
contract
that
can
pay
for
its
own
deployment
and
you
have
a
mechanism
that
can
pay
for
the
deployment
and
for
execution
transactions.
The
next
thing
to
think
about
is
that
I
want
to
make
operation
on
multiple
networks.
A
A
B
Just
the
event
driven
flows
because
they're
very
interesting,
maybe
a
couple
of
examples,
one
let's
say:
there's
an
nft.
That
means
at
a
certain
time.
Then
you
don't
have
to
wait
in
front
of
your
computer
and
then
you
just
like
create
the
transaction.
Then
you
could
pre-register
the
transaction
into
into
a
like
a
registry
contract
of
pending
transactions
and.
C
B
A
Okay,
with
the
ear
three
four,
three,
four,
three
two
seven:
we
wanted
to
create
an
implementation
of
a
counter
obstruction
that
can
be
a
executed
today,
not
something
we
have
to
change
the
protocol,
but
something
we
can
add
today.
So
we
Define
a
mempool
of
what
we
call
a
user
operation.
User
production
is
a
transaction
in
our
terminology.
A
B
A
Okay,
so
our
implementation,
what
it
does
it
takes.
I
said
these
user
operations.
They
know
you
no
longer
need
an
eoa
to
send
this
user
operation.
The
node
themselves.
Take
the
user
operation,
collect
them
into
batches
and
put
them
on
chain
perform.
The
validation
that
is
validation,
is
the
signature,
nonce
and
the
payment
and
then
perform
the
execution
that
you
want
to
make
a.
A
A
A
Where
we
we
want
to
take
it
to
the
next
level
right
now,
when
you
create
a
an
account
obstructed
wallet,
we
want
to
make
it
a
first-class
citizen
on
the
network.
First
Class
A
account
on
the
network
right
now.
It
isn't.
It
is
second
class
because
there
are
some
differences
between
UI
accounts
and
some
applications
require
eoa
accounts
in
the
way
they
work
in
the
way
they
require
signature.
Think
of
permit.
You
cannot
do
permit
directly
with
a
Wallet
account.
A
We
do
want
to
make
them
first
class
citizens,
so
the
next
stage
after
what
we've
done
today,
which
is
having
a
contract-based
mechanism
to
deploy
them
on
chain,
we
want
to
add
them
into
the
network,
to
what
we
call
enshrine
437
into
the
network,
so
that
account
abstracted
accounts
will
be
account
and
transaction
in
the
system,
just
like
normal
accounts
and
then
to
make
it
possible
to
convert
any
eoa
account
into
a
smarter
into
account,
obstructed.
That
is,
there's
going
to
be
a
way.
A
It
is
not
fully
hashed,
yet
it
will
take
some
time
until
we
finish
it
and
until
it
be
approved
into
the
network,
but
there's
going
to
be
a
way
that
you
have
a
normal
account
and
you
want
to
have
those
extra
features,
so
you
will
be
able
to
enable
this
account.
There
are
several
ways
how
to
do
it.
One
of
them
is
that
you
will
actively
have
to
convert
your
account.
Your
account
into
a
smart
account,
abstract
account.
A
The
other
way
is
that
they're
going
to
be
some
point
of
in
time
where
all
eoa
accounts
will
become
abstracted,
but
with
a
default
implementation
that
emulate
completely
the
normal
eoa
account.
And
from
that
point
you
can.
Yes,
you
can
keep
the
same
implementation
or
you
can
switch
to
a
different
implementation.
If
you
want
a
extra
features
like
all
of
those
that
we
described
earlier.
B
So
one
one
one
thing
to
maybe
refine
a
little
bit
is:
we
believe
eoas
will
need
to
go
away
at
some
point
so
right
now
they
are
enshrined
into
the
protocol
and
we've
discussed
some
of
the
limitations
around
that.
So
at
some
point
eoas,
even
if
there's
backwards
compatibility,
they
will,
they
will
not
be
a
part
of
the
protocol
anymore.
B
We
don't
necessarily
think
that
it
makes
sense
to
enshrine
any
specific
alternative.
Like
you
know,
this
is
an
ERC.
Maybe
there
will
be
like
you
know,
improvements
in
the
future,
because
that
could
be
dangerous,
but
what's
clear
is
abstract?
Accounts
are
going
to
be
enshrined
into
the
protocol.
There
are
going
to
be.
There
are
going
to
be
accounts
that
can
do
all
the
things
that
we
discussed
out
of
the
box
for
new
deployments
and
for
older
deployments.
B
A
Okay,
what
can
we
do?
You
can
start
experimenting
with
a
esc-4337a
now
I
see
people
who
experimented
here
in
the
hackathon
and
yes
over
there.
Also
a
you
can
add
useful
features
to
your
accounts.
Innovate
do
whatever
you
like,
and
if
you
find
something
that
you
think
is
good
for
the
public,
you
can
apply
for
an
EF
Grant
and
they.
A
What
they
and
anything
building
adapt,
as
we
said,
accounts
wallet
accounts,
are
a
bit
different
from
UI
accounts.
So,
even
today,
when
you're
working
with
apps,
this
is
not
strictly
related
to
account
abstraction,
but
to
Wallet
account
in
general
make
sure
that
you
are
not
forcing
the
user
to
use
a
accounts
like
if
you're
checking
signatures.
There
is
an
extension,
the
1271
that
allows
a
Wallet
account
to
check
a
signature
because
it
doesn't
have
a
signature
by
itself.
A
Wallet.
A
Yes,
yeah,
if
you
have
a
token,
you
want
to
have
permits,
be
aware
that
permit
as
it
is
today
in
usdt
and
die,
does
not
support
a
Wallet
account.
You
cannot
use
it
from
a
Wallet
account,
but
again
because
it
uses
the
signature.
There
are
some
other
tweaks
like
TX,
origin
and
stuff
again
in
general,
try
to
be
supportive
for
wallet
accounts,
because
these
are
the
future,
not
only
the
glossy
safe
today,
but
also
account
obstructed
in
the
future
and
also
if
you're,
using
gas
sponsorship
models
should
also
think
about
it.
How
to
interact.
A
B
And-
and
the
last
item
would
be
regarding
wallets
if
you're
developing
dapps,
then
maybe
there's
some
space.
If
you
you
find
that
well,
it's
not
supportive
enough
of
a
contract
wallets.
Then
you
can
voice
your
concerns
and
and
try
to
lobby
for
that
as
a
as
adapt
developer.
That
that
really
helps
so
you
know,
getting
everyone
on
board
is,
is
a
is
a
process
that
we
could
use
your
help
on.
B
C
So
I
have
like
two
questions
like
one
are
related
to
how
currently,
like
account
abstraction
exists,
as
of
today
as
an
implementation.
Can
you
provide
an
example
like
how
like
it
can
be
potentially
used
in
a
way
as
it
is
in
present
form,
and
the
second
question
is
related
to
The
Next
Step,
like
they're
like
curious
about
like
smart
contracts
containing
code,
then
like?
Is
there
a
distinction
between
operation
that
involves
the
smart
wallet,
calling
its
own
code
versus
calling
the
code
from
a
different
contract?
A
That
we
have
in
our
source
code
that
your
wallet
need
to
inherit,
provide
a
method
or
two
and
then
the
contract
wallet
supports
account
obstruction,
there's
also
sample
how
we
add,
on
top
of
existing
ignosisafe,
without
touching
the
code,
adding
a
module
to
make
it
account,
obstructed,
enabled
and
you
do
need
a
wallet,
application
or
browser
extension
that
will
be
able
to
use
it.
We
have
the
basic
SDK
how
to
write
it.
There
are
several
wallets
Soul
wallet
described
behind
the
behind
you,
a
demonstrated
the
hackathon
and
also
a.
C
A
Wallet
a
hackathon
project
that
try
to
use
there
are
no
implementation
in
existing
wallet
like
metamask,
doesn't
support
it
right
correct.
Currently,
you
have
to
use
some
other
wallets,
but
this
is
now
in
the
work.
There
are
several
wallets
that
are
adding
account
obstruction
support
regarding
how
the
call
is
done,
the
basic
solidity,
it's
a
wallet,
is
a
contract
when,
when
someone
make
a
call,
it
validates
it
is
allowed
to
make
this
call
that
is
either
the
owner
or
through
account,
obstruction
the
validation
method,
and
then
it
makes
a
call
outside.
F
So,
regarding
smart
contract
wallets,
so
can
you
can
you
comment
on
the
situation
on
when
you
need
to
use
L2
Solutions,
because
in
most
of
the
cases
you
you
cannot,
because
you
have
a
small
contract
wallet
Deploy
on
mainnet
and
you
cannot
deploy
it
on
the
same
on
this
on
on
every
L2
like
arbit,
room
or
Optimus,
because
it
you
know
it's.
It's.
F
A
C
A
A
Implementation
of
that
is
happening
when
you
just
funding
your
wallet
the
first
time.
Think
of
it,
you
open
your
wallet
software,
you
see
the
address,
it
is
not
deployed
anywhere.
You
see
my
your
address,
you
go
to
index
and
you
move
eth
or
whatever
into
it,
and
then
you
make
a
transaction
with
that
wallet.
A
D
I
guess
we
all
agree
about
like
the
importance
of
account
abstraction,
and
this
is
what
Luxo
was
working
on
like
starting
from
2018
and
like
starting
with
ERC
725
standard
but
and
I
was
checking
the
the
CRC
like
way
before
and
like
I
couldn't
understand,
because
it
was
way
like
too
complicated,
but
I
have
just
two
questions
like.
Can
you
explain
more
about
like
how
users
can
choose
the
implementation
and
about
like
the
cross
chain
execution
and
just
an
open
question?
Maybe
we
can
discuss
that
later?
D
Like
don't
you
think
that
the
standardization
of
the
account
up,
like
the
account,
need
more
standard
laser
standardization
of
other
stuff
like
I,
will
give
you
an
example.
If
you
have
a
like
a
your
account
needs
to
receive
token,
it
needs
to
implement
on
erc721
received
on
your
c1155
received
and
token
received
for
erc223,
but
like
what,
if
we
come
up
with
a
new
standard
in
the
future
like
on,
we
need
on
ERC
6700,
maybe
and
like
maybe
also
we
need
something
related
to
followers
or
like
I.
Don't
know
why?
D
A
Later,
if
you
want
I'll
try
from
the
beginning,
yes,
there
were
wallet
accounts
before
account
obstruction.
They
exist
from
the
beginning
of
a
ethereum
which
is
not
far
away,
but
they
exist.
We
didn't
invent
the
wheel.
We
created
a
standard
which
allows
the
framework
which
allowed
nodes
to
support
such
accounts
accounts
to
be
able
to
behave
as
close
as
possible
to
your
accounts
like
pay
for
their
own
deployments,
which
would
be
tricky
it's
possible.
We
we
created
one
there.
A
Yes,
the
AP
is
complex,
but
most
of
these
complexity
comes
from
these
protection
mechanisms.
If
we
should
rewrite
it
in
a
way
that
is
more
account
friendly,
because
most
people
don't
Implement
a
bundler,
they
want
to
implement
an
account,
so
they
need
to
know
what
they
have
to
do.
Maybe
some
of
the
limitations
they
have
on
what
they
do
and
they
don't
care
about
the
low
level
implementation.
Yes,
editorial
work
is
required
for
this
spec
I
agree
and
they
of.
A
A
cross
chain
execution,
let's
take
it
off
chain
again,
nothing
of
it
is
in
the
core
of
the
EIP,
like
BLS,
there's
no
BLS
in
the
core.
What
there
is
in
the
core,
for
example,
is
the
ability
to
do
signature
aggregation
that
you
check
the
aggregation
in
one
place
for
entire
batch.
This
is
in
the
core.
Bls
is
merely
an
implementation
of
that
we
narrowed
several
interface.
You
add
another
contract
to
perform
it,
but
it's
separate
from
the
core,
so
it
is
modular
all
the
features
like
specific
feature
of
wallets.
A
A
B
E
B
Your
office,
your
office,
is
watching
us
and
sending
us
sending
us
messages
trying
to
participate
in
the
question
and
answer
session.
You've
just
said:
hey,
like
what
happens.
Post
validation
is
not
part
of
the
standard.
It's
not
part
of
erc4337
and
anything
anything
can
happen.
We
can
talk
about
ideas
on
how
to
make
it
happen,
but
it's
not
specifically
related
to
The
Standard
that
we're
working
on
right
now.
A
E
G
So
how
can
you
make
sure
that
you
know
a
wallet?
A
smart
contract
wallet
will
be
able
to
prove
that
is,
for
example,
only
controlled
by
one
individual
versus
multi-six
such
that
the
receiving
contract
can
make
a
judgment
call
on
whether
it
should
reject
or
accept
that
call
right.
So,
for
example,
if
I,
if
I
have
right.
A
So
we
have,
we
have
a
separation.
Okay.
The
model
we
have
is
like
this.
A
smart
contract
has
a
separation
between
validation
and
execution.
Execution
is
anything
it
calls
out.
You
know
you
execute
external
content,
whether
it's
atone
another
validation,
gets
the
user
operation
and
validates
whatever
it
likes.
The
minimum
is
validated
signature
and
validate
the
non
so
that
it's
not
a
replay
and
it's
a
valid
signer,
but
it
can
do
more.
A
It
can
check
the
actual
executed
method
and
say
a
okay
I
restrict
access
to
this
destination
or,
if
it's
a
complex
rule,
I
restrict
access
to
this
destination.
For
this
signer,
because
I
have
multiple
sign
and
each
one
has
a
different
role
and
is
allowed
only
specific
method.
The
Target
contract,
like
a
token
usdc
token
usdc
token,
doesn't
receive
all
this
information.
A
G
Sure,
yes,
it
is
complex!
Yes,
if
you're,
if
you're,
if
your
target
smart
contract
does
not
have
you
know
additional
computational
things
going
on
that
that
require
it
to,
for
example,
if
so
take
royalties,
for
example,
right
if
I,
if
I
have,
if
I'm,
if
I
can
I
can
circumvent
royalty
payments
if
I
transfer
an
asset
from
from
from
from
Alice
to
Bob,
right
and
and
right
now,
if
I
with
an
eoa
I,
actually
have
to
transfer
the
the
private
key
to
circumvent
the
the
the
the
royalty
payment.
G
B
A
G
A
If
you
want,
and
while
you're
doing
something
illegal
I'm,
not
saying
it
is
I'm
not
saying
that
we
support
it,
I'm
saying
that
a
contract
May
support
it.
For
example,
if
you
want
a
soul-bound
wallet
that
you
can't
transfer
the
owner
at
all
right
go
ahead,
create
such
a
wallet.
If
you
want
a
wallet
that
doesn't
support,
set
implementation
then
create
a
wallet
that
will
refuse
to
change
implementation.
Once
you
fixed
you
reach
that
implementation,
you
don't
allow
to
change.
You
can
create
such
an
implementation.
We
don't
block
such
an
implementation,
but
we
support
others.
G
To
communicate
what
type
of
wallet
implementation
it
is
such
that
the
the
targeting
contract
can
can
check
whether
because
you
you
don't
know
right,
it's
like
it's
like
it's
like
whether
the
targeting
contract
needs
to
know
the
context
of
the
wall,
implementation
to
make
a
judgment,
call
about
the
owner.
Okay,.
A
First
of
all,
target
contracts
out
there
in
the
wild,
don't
know
anything
about
the
collar,
except
that
it
is
a
message
center.
They
can
check
the
code
if
they
like,
but
you
are
talking
about
the
use
cases
that
don't
exist
with
EOS,
so
they
really
knew
also
for
us.
Smart
contract
calls
for
any
operation.
You're
talking
about
the
other
thing.
You
talk
about
standardization,
how
to
know?
Yes,
it
is
required.
A
We
are
providing
right
now
the
infrastructure
for
account
obstructions
for
wallets
to
be
built
about,
on
top
of
it,
standardization
between
the
account
contracts
and,
for
example,
the
wallet
application
that
use
them,
something
that
the
the
ecosystem
will
benefit,
but
it
doesn't
exist
yet
because
neither
the
wallet
nor
the
nor
the
contracts
exist
today.
So
usually,
it
will
be
a
siled
like
a
given
application
with
a
given
a
a
given
wallet
contract
with
a
given
a
UI
ux
for
it,
but
we
won't.
A
B
H
H
A
Because
I
don't
need
it
anymore.
Open
GSN
tried
to
do
a
gas
abstraction
which
we
later
implemented
into
account,
abstraction
for
existing
eoa
accounts
and
the
requirement
of
the
gas
station
network
and
network
of
three
layers,
which
are
the
actually
standards
of
transactions,
meant
that
the
Target
contract
being
token
or
other
couldn't
tell
the
real
sender.
So
we
they
had
to
be
modified
support
eip2771
at
the
method,
so
that
it
can
tell
the
real
sender,
which
is
a
pain.
A
It's
it,
because
adaptation
of
this
requires
the
Target
contract
to
be
changed,
doesn't
support
existing
tokens,
for
example.
If
you
want
your
token
to
be
meta
transaction
enabled
you
have
to
rewrite
it.
So,
yes,
it
was
problematic.
It
was
good
for
dapps
to
add
support
for
existing
users
to
sponsor
the
gas
account
obstruction.
They
has
a
Much
Higher
Goals
to
replace
the
accounts,
and
it
supports
almost
all
existing
contracts,
as
I
said,
with
the
limitation
of
contracts
that
limit
themselves
to
EOS,
it
supports
any
contracts
on
the
Chain,
all
tokens,
for
example.
A
I
I
I
A
Okay,
the
answer
for
the
question.
The
first
question
is
all
of
the
above
or
any
of
them,
because
each
wallet
can
decide.
As
I
said,
we
had
a
wallet
here
in
that
demonstrate
how
to
use
zero
knowledge
proof
instead
of
signatures.
Another
wallet
that
implements
the
RSA
signatures
from
your
phone.
You
want
eoa,
yes,
our
simple
implementation
uses
in
eoa
is
an
owner,
but
it's
just
one
implementation,
the
other
question
regarding
Earth
and
Oscar.