►
From YouTube: 5 Smart Contract Patterns I Wish More Devs Would Use
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 Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/5-smart-contract-patterns-i-wish-more-devs-would-use/
A few creative and undervalued smart contract design patterns that could help you build more effectivelly.
Speaker(s): Hadrien Croubois
Track: Developer Infrastructure
Keywords: Solidity,ERC,tricks
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
That's
particularly
true
of
defy,
and
the
first
thing
you
should
do
when
writing
a
smart
contract
is
make
sure
that
you
are
leveraging
as
much
composability
as
possible
and
trying
to
make
sure
that
your
contract
can
interface
with
all
the
existing
tooling.
That
would
be
relevant
an
example.
Is
people
always
ask
us
like
hey?
Can
we
make
an
honorable
contract
payable,
like
someone
could
buy
it,
and
this
makes
really
no
sense,
because
there
is
already
a
lot
of
tooling
for
buying
assets
and
that's
the
nft
space
in
the
nft
space.
A
You
can
just
buy
anything
from
openc
or
variable
or
any
other
marketplaces,
and
we
don't
want
to
redeploy
that
for
for
the
NF
for
the
ownable
contracts
that
that
exists.
So
the
idea
is
that
when
own
ability
is
just
like
the
ownership
of
of
a
contract
in
order
to
to
have
access
to
it
to
some
admin
functions.
Well,
you
could
just
turn
that
into
an
erc721
and-
and
this
is
how
you
would
do
it.
Basically,
you
can
very
simply
say,
like
hey.
A
My
owner
is
just
the
owner
of
a
specific
token
on
an
ownership
registry
and
I
can
have
a
normal
owner
modifier
for
that
and
when
I
want
to
transfer
ownership.
The
only
thing
I
will
have
to
do
is
go
to
this
ownership
registry
and
try
to
transfer
as
a
corresponding
token,
no
on
the
ownership
registry.
You
would
have
to
override
the
either
approval
order
function
to
allow
that,
but
that's
very
easy
to
do,
and
so
here
in
this
example,
you
have
a
basic
Factory.
A
This
is
actually
live
on
mainnet
and
when
you
want
to
deploy
a
new
vesting
wallet
with
a
beneficiary
for
it.
Well,
here's
the
beneficiary,
it's
just
the
owner
of
the
nft
on
this
Factory
and
when
I
deploy
a
new
contractor,
just
create
a
new
clone,
I
initialize
it
and
I
mean
the
token
and
that's
the
equivalent
of
my
owner.
If
the
contracts
were
ownable,
the
difference
is
here:
my
contract
show
up
on
openc
and
I
can
basically
sell
it
or
transfer
it
very
easily.
A
If
you
want
to
go
a
bit
further,
you
can
even
have
like
a
universal
address
ownership
registry,
which
I
think
is
pretty
fun
because
it
allows
you
to
get
rid
of
the
minting
part
by
just
saying
that,
hey
by
default,
all
the
tokens
are
already
minted
and
they
are
owned
by
the
address
that
corresponds
to
the
Token.
Id
I
mean
all
the
token
ID
that
matches
an
address
in
exactly
smart
form,
and
then
you
can
just
say
that
hey,
it's
not
possible
to
burn
them.
A
You
would
just
send
them
back
to
the
original
owner,
and
there
is.
This
is
approval
ownership
that
I'm
doing
some
fancy
stuff
with
codes,
but
you
don't
need
to
care
about
that,
and-
and
this
can
just
be
another
approach-
I
think
it's
nice
and
it
it
shows
creative
use
of
your
season.
21S,
and
another
thing
we
use
is
that
ownable
obviously,
is
something
that
a
lot
of
people
are
familiar
with,
but
the
granularity
is
really
bad.
A
Sometimes
you
have
different
admin
functions
in
your
contract
that
you
want
to
have
different
access
for,
and
access
control
does
that
pretty
well
access
control
is
provided
by
open
Zeppelin.
The
thing
is
that
access
control
is
maybe
a
bit
more
difficult
to
work
with,
because
you
cannot
transfer
a
world,
you
need
to
Grant
it
to
someone
else
and
then
either
get
it
revoked
or
renounce
it,
and
so
it's
very
nice
for
some
users,
but
at
the
same
time
own
ability
has
some
advantages.
A
So
it
can
grant
any
other
one
and
this
here
it's
ownable,
but
it
could
be
the
ownable
registry
official
just
before
so
you
could
have
a
contract,
whereas
the
owner
is
the
nft
orders
and
then
you
have
all
these
access
controls
that
are
managed
in
that
way
or
you
could
be
creative
and
use
ERC
1155s
here
and
so
yeah.
That's
that's
just
some
small
ideas,
but
it's
not
very
complex,
good
I.
Think
everybody
can
understand
that.
A
So
these
are
just
two
small
pieces
of
code
like
0.4s
and
five
that
I
came
up
with
very
recently
and
I.
Think
that's
that's
things
that
are
are
interesting
because
we
never
expect
a
hard
Fork
to
happen
until
it
actually
does,
and
people
start
trying
to
do
a
proof
of
work,
blockchain
and
then
the
bridges
that
are
on
this
proof
of
work
chain
starts
breaking
and
that's
a
pain.
A
But
if,
for
any
reason
there
were
to
be
hard
Fork,
the
version
of
the
bridge
that
is
on
the
chain
that
changes
the
chain
ID,
then
all
those
would
be
automatically
disabled
and
you
get
into
recovery
mode
when
some
like
multisig
would
be
able
to
take
over,
and
this
multi-seek
is
not
a
threat
for
the
user
on
the
legitimate
chain,
because
because
of
this
only
fork
chain
like
this
admin
cannot
do
anything
nasty
to
your
users.
But
that's
that's
a
mixing
point
that
would
have
saved
some
pain.
A
I
mean
it
wasn't
the
proof
of
work
chain.
So
maybe
we
don't
care
a
lot,
but
who
knows?
Maybe
there
will
be
more
legitimate,
Forks
at
some
point
in
ethereum's
life
cycle
and
another
one.
Is
that
that's
something
we
provide
as
open
the
screen
and
that's
what
we
call
the
multi-code
contract
and
that's
very
simple:
it's
just
one
endpoint
one
small
functions
that
allows
you
to
delegate
to
yourself
with
an
area
of
data
and
that's
very
easy
for
you
to
integrate
into
any
of
your
contract
and
I.
Don't
think
there
is.
A
There
is
any
reason
not
to
do
it
and
the
way
it's
being
done
is
earlier.
We
saw
this
example
here,
and
here
you
have
this
multiple,
that
maybe
you
didn't
see
because
it's
red
on
black,
so
it's
not
really
visible,
but
what
it
allows
you
to
do
is
when
you
went
to
create
a
new
vesting
for
one
of
your
investors
or
someone
when,
if
you
have
10
or
20
investors,
maybe
you
don't
want
to
do
20
transaction
that
do
20
calls
to
this
new
wasting
function.
A
A
In
order
to
do,
it
will
basically
run
like
all
these
these
operations
so
deploy
Trend
investing
at
a
time
or
you
could
do
an
approve
and
some
something
else
or
you
could
batch
transactions
together
like
you,
don't
need
to
wait
for
Icon
abstraction
to
batch
transaction.
You
can
already
do
it
at
the
contract
level,
I
mean
providing
that
the
target
is
the
same
contract
for
all
the
subcodes
and
that's
as
simple
as
including
that
so
yeah.
A
A
A
There
are
different
kind
of
smart
wallets
if
it's
just
something
that
QRS
sole
owner
of
I'm,
not
sure
it
brings
anything
new
to
the
table.
But
if
you
are
doing
a
multi-sig,
maybe
it
will
be
relevant.
I
mean
my
opinion.
Is
that
a
time
lock,
for
example,
is
a
kind
of
North
wallet,
because
it's
just
someone
that
will
manage
asset
and
do
operation
with
three
specific
rules
and
in
the
open,
zip
time
lock.
A
We
use
Access
Control
to
separate
the
role
of
the
proposers
from
the
executors
from
the
admin
that
may
have
the
right
to
cancel
potentially.
So,
yes,
if
you
are
building
a
multi-cig
and
you
want
to
have
different
privileged
access,
maybe
I
think
an
overseer
that
is
able
to
recover,
in
case
of
of
issue
having
signers,
having
proposers
that
basically
you're
turning
your
emergency
into
some
governance
mechanism,
which
which
it
basically
is
what
time
will
see,
is
a
governance
mechanism.
So,
yes,
you
could
use
Access
Control.
B
A
Yes,
it
would,
but
it's
not
possible
right
now
so
like
if
we
had
a
EIP
3074
live.
We
could
just
have
this.
Make
use
this
OS
and
oscore
mechanism
to
do
batching,
transaction
and-
and
you
would
not
have
to
include
that
in
your
contract.
The
thing
is
that
this
is
not
available
now
it
will
not
be
available
until
at
least
Shanghai
and
maybe
later
so
I
think
the
bytecode
increase
is,
is
really
small
compared
to
the
the
value
that
is
added
to
your
contract
right
now,
but
yeah
in
the
long
run.
C
Hey
great
talk
by
the
way
in
the
ownable
ERC
721
part,
you
were
talking
about
how
you
could
basically
ditch
the
ownable,
the
ownable
library
right,
what
what
advantage
I
I
kind
of
missed
the
point
of
like?
What's
the
advantage
of
implementing
the
ownership
inside
the
erc721
logic,
instead
of
just
bringing
ownable?
Is
it
just
like
byte
code
size
or
is
there
any
other
advantage
that
I'm
missing
no.
A
The
weird
advantages
in
in
composability
so
examples,
for
example
your
your
own
Apple
contract.
It
could
be
tied
to
assets.
Maybe
you
would
want
to
consider
that
as
a
class
of
its
own,
that
you
would
be
able
to
land
against
collateral,
or
maybe
it's
maybe
it's
like
a
vessing
wallet
that
is
basically
a
future
financial
future
that
you
want
to
sell
on
unisa
on
openc
right
now.
You
cannot
sell
a
non-able
contract
on
openc,
but
you
can
sell
an
nft.