Exemple of a permit contract in CameLIGO
ligo init contract --template permit-cameligo [PROJECT_NAME]
This example contract implements an FA2 multi-asset contract with a TZIP-17 extension.
In this implementation, permits can be submitted and consumed in separate-steps.
Permits have 2 main use cases:
- making gasless transaction
- avoiding manipulating operators (FA2) or allowances (FA1.2) when a transaction must be done by a third party
The contract is written in
cameligo flavour of LigoLANG,
to be able to compile the contract, you need either a ligo binary,
For deploy scripts, you also need to have nodejs installed, up to version 14 and docker if you wish to deploy on a sandbox.
make installto install dependencies
make compileto compile the contracts
make deployto deploy the contracts. You need to rename
deploy/.envand fill the required variables.
You can also override
make parameters by running :
make compile ligo_compiler=<LIGO_EXECUTABLE> PROTOCOL_OPT="--protocol <PROTOCOL>"
Use case: taco shop loyalty program
A potential use case is the digitalization of the good old loyalty card.
Loyalty Token creation
Expanding on the taco shop tutorial, let's say Pedro creates a new token to reward his customers.
Pedro rewards his customers with one token for each taco bought.
Alicia is a regular client of the taco shop. She already accumulated 10 tokens, which can be exchanged for a free taco. One day, she happens to be out of tez, so she decides to use her tokens to pay.
So, she asks Pedro to create a permit. The permitted action will be the transfer of 10 tokens from Alicia to Pedro. Once Pedro has verified the permit parameters given by Alicia, he calls the smart contract with them, registering the permit.
The last step consists in Alicia asking Pedro to consume the permit, by revealing
him the parameters she used for the permit creation, allowing Pedro to call the
transfer entrypoint with these parameters, actually consuming the permit.
On top of FA2 standard, the following entrypoints are implemented:
permit: allows any sender to register a permit.
setExpiry: allows any sender to change its expiry configuration for its own permits. (intended camel case to comply with tzip-17)
transfer: overrides FA2
transferto add the handling of permitted parameters.
Additionally, for the use case presentation, 3 entrypoints have been added:
create_token: creates a token.
mint_token: mint a token.
burn_token: burn a token.
set_admin: to set the authorized account for the 3 above entry points.
Smart Contract Data Types
|requests||list (owner: address, token_id: nat)|
|callback||contract list ((owner: address, token_id: nat), balance: nat)|