I'm honored to be here i'm jordan valina
I'm a developer and answering fan and
founder of givethe I'm a little
distracted today because just now in
Catalonia there were eight members of my
government detain it for defending
democracy and my people right of
self-determination we have a huge
opportunity to bring the center lights
tools - dreaming catalonia we need it
but I'm here to share a bit of my
passion for smart contracts in this
presentation I will first talk about the
mini-me token contract then give you
some highlights on how I see the future
of token contracts and finally I will
briefly introduce my latest development
the liquid pledging contract which we
are currently using at givethe let's
start with the mini-me contrac mini-me
has been developed a year ago it was it
follows the year C 20 token a standard
and has been used extreme extensively by
many important projects in the interim
space here you can see some of these
projects from City Oregon status given
district 0x and many others so what
makes mini-me contract different it's
more than just a simple year C 20 token
contract the token has many
functionalities that any tab may need
these functionalities includes creating
and destroying tokens black or white
listing addresses freezing transfers
among others but let's get to the real
innovation of what it is of what is a
smart contract the contract tracks the
token distribution history on the
blockchain this property is what makes
mini-me contract different
and allows this token to be cloneable
for cable if you want that means that
you can create a new token whose initial
distribution is the same as the original
token this clone fork can be done at any
given block in the past or can be said
for the future after the fork each clone
token is independent of each other much
like it is a fork or BT Bitcoin cash for
it all these properties do not count for
free and the main disadvantage of
choosing Minami token is that the gas
cost of each transfers is a little bit
higher that the non clone of all ones
all these functionalities are important
for the next use cases the first one and
one of the most important one is the
voting application use it in many
governance systems this means that at
the beginning of a voting process a
clone token is generated and born after
the token holder boats making it
impossible for him to vote twice using
the token contract this way prevents
having to lock the mine token while the
boating token was the voting takes place
another interesting application is the
distribution of rewards among talking
holders when you want to distribute your
words on a regular basis it's possible
that you ran in the problem that the
distribution of the token may change as
token holders trade the coin mini-me
solve this problem because you know the
balance of any token holder at any time
in the past so you can easily create a
contract that distributes rewards
according to the holdings that each
token holder had at the moment its
reward both issued the same way you
create a boating token you can also
create many functionalities like this
cone token or
rotation token a disk on token would
work this way the disk on token may be
used to buy another token at a given
discount and it will be redeemed when
the new tokens are purchased and the
discount is supplied another usage is to
create a token for a spin-off down the
mini token also makes your project
future-proof making it easy to upgrade
to a new version of the contract but
probably the most incredible facet of
this token is that anyone can create a
clone token in permissionless way so
that anyone can add value to the
community let's talk now a little bit
about the future of the token smart
contracts the future clearly points to
the ERC two to three standard proposal
there is mainly one operation in this
standard that operation is transfer and
with this transfer you can attach data
once the transfer is done if the
recipient is a contract the token
fallback function is of the recipient is
called with this extra data as you can
see the mine idea of this standard is to
work very much like either works right
now this estándar is not ready yet to
get there the two main points that needs
to be resolved our first backwards
compatibility which I think it's
solvable for example you can always
create rubber contracts in the worst
case and the other point that is
necessary in my opinion is to define a
pseudo introspection stander mainly
through the introspection means that you
can ask to a smart contract about the
implementation of a specific interface
to standardize this we currently have
two very different proposals JP 165 and
the AAP six seven to
EAP 165 is very straightforward you just
define a support interface function that
is the smart contract may implement then
anyone can use this function to query if
this contract implements a specific
interface or not
the other proposal ip67 to in my opinion
makes more sense and it's much more
scalable the idea of EAP success 6 7 2
is to use reverse ENS to keep a database
of interfaces implemented on each
existing contract let me give you an
example of how this would work imagine
that a contract implements a token
fallback interface and the constructor
of the token would add this entry in the
reverse ENS for people that don't know
how reverse ENS works it mainly defines
a domain for each address normally this
address is assigned to a human readable
name so you can set a name for your
address but you have full control of
this special domain assigned to your
address so you can create subdomains in
our case we define a subdomain
with the interface name that the
contract implements and make it point to
the address responsible for implementing
the interface in most cases this will
point to itself if the contract
implements the interface but that not
strictly necessary and this is where the
standard gets interesting this entry can
point to a different proxy contract
think about it this allows for future
functionalities and future interface to
be easily supported when they come
coming back to the year see 2 to 3
standard one of the biggest shortcomings
is that it cannot transfer tokens to the
current multi-sig implementation because
they are contracts that don't implement
the token fallback function to work
around these
a new version of the multi-sig should be
deployed but this can be solved easily
with a ip67 - by creating a reverse E&S
entry for the iTalk and fallback
interface that points to a proxy
contract that just accepts the transfer
and this is very exciting this also
gives the possibility of executing some
code not only when tokens are sent to a
contract but also when tokens are sent
to a regular account if you assign a
proxy to a regular account you can for
example prevent receiving a payment you
don't want or trigger any code you
desire when regular account receives
tokens at this point if you put together
all the minimal functionality and the
year see 2 to 3 token with the a ip67 -
we get a super flexible contract this is
the new token contract giveth is working
on right now
we call it internally yoga token you can
imagine in choir in my opinion this yoga
token could be a perfect candidate to be
considered for a standard aetherium
token especially if the theory on base
government systems like carbon boating
or protocol voting are to be developed
of course the gas problem may still be
an issue but this can be minimised by
enforcing only epoch snapshots instead
of blocking up shots now the last topics
to finish this talk I would like to
introduce liquid pledging this is one of
the main open-source mark contracts that
have been developed at givethe well not
exactly a token contract it extends some
powerful functionality that can be
applied to any token what's liquid
pledging about liquid pledging is where
requite democracy meets fund management
essentially you can
your tokens or let someone else manage
them with oversight with a normal wallet
you manage your tokens you have a
balance you have transfer functions
inputs outputs and that's effectively
all with liquid pledging not only you
can manage your own tokens but you can
also manage someone else's tokens you do
this by creating a hierarchical chain of
delegation you can give the authority of
the tokens to a delegate the delegate
can do the same with a sub delegate and
so on the most important feature is that
after you delegate the tokens you are
still empowered to make decisions
regarding the use of these tokens as the
owner you have the complete oversight to
make it clear let me give you an example
gap is a community member
that's very concerned for security in
the blockchain and once to the Nate 100
inner two projects that improve security
he wants to do good but he is very busy
person and don't have the time to
analyze all the projects in the space on
the other hand we have wookie who is
very active member of the community and
also very much concerned with security
he has complete overs overview of all
the projects in the space and know which
key projects should be supported with
liquid pledging gap can delegate the
authority over his 100th ether to baki
- so he can select the right project
boo-ki decides that the best one to
support is the two factor authentication
frost project for my other world so he
pre-commit the aether at this point Deb
has three days or any time
pre-configured to veto if he done
doesn't if he does not agree with bogies
choice but if he does nothing
my the wallet project is a great
supporter this can be a normal account
or it can have a smart contract plug-in
attached where a reviewer let's call
this reviewer grief if grief decides
that the work is done the ether go to
tailor for successfully implementing
two-factor authentication but if the
project does not meet the conditions it
in the in the given amount of time he
can cancel the project and the money
goes back to Buki and gap and gap has
again oversight over how the 100 either
can be used as you can see this contract
has many advantages
the owner has full control of the tokens
full transparency and knowledge of where
their phones go I want to mention that
this contract is all is also extensible
contract via plugins in these plugins
you can add a specific condition like
token allocation when the project is
phoned or setting a harp at for a
haircut for exceed for a given project
the liquid pledge account the liquid
logic contract can be used not only for
donations but also for organizations
management in an organization they the
investors delegates the funds to Co the
CEO soup delegates that the budget to
the directors the city of delegates to
the system department and so on and the
investors still have full control on
where the funds are spent and invested
the same idea applies in fund management
where a delegate pre commits the ether
to a specific projects and the investors
has the last word on where the
investment goes there are many other
great ideas one that I like a lot is
liquid lending and by the way this is
done from a startup from Mexico
it's called Aurora Libre in this concept
a microcredit is made via a higher
akiko delegation chain of trust to wrap
up I would like to leave you with three
key takeaways first if you need an
advance talking contract consider the
mini-me contract which has been fully
tested and implemented second the yoga
token it brings together the features of
mini-me plus the year C 2 to 3 with with
a ip67 - this is a powerful token to be
considered as a standard for the theorem
community once the standards are
approved and third the liquid pledging
contract could be ideal I could be ideal
for many usages
it's especially sweded or block chain
based donation systems that can make a
world a better place but it could also
add interesting functionalities for many
dubs and no we have reached the end of
my talk I welcome comments and feedback
please feel free to reach out to me to
grieve or to any givethe team members if
you want to learn more about our open
source contracts you can always you can
always check or a guy giveth dot IO
website here are some links and thank
you to the foundation for having me here
and thank you to all of you for your
attention
[Applause]
you
[Music]