The Taco Shop Smart Contract
Meet Pedro, our artisan taco chef, who has decided to open a Taco shop on the Mavryk blockchain, using a smart contract. He sells two different kinds of tacos: el Clásico and the Especial del Chef.
To help Pedro open his dream taco shop, we will implement a smart contract that will manage supply, pricing & sales of his tacos to the consumers.
Pricing
Pedro's tacos are a rare delicacy, so their price goes up as the stock for the day begins to deplete.
Each taco kind, has its own max_price
that it sells for, and a
finite supply for the current sales life-cycle.
For the sake of simplicity, we will not implement the replenishing of the supply after it has run out.
Daily Offer
kind | id | available_stock | max_price |
---|---|---|---|
Clásico | 1n | 50n | 50mav |
Especial del Chef | 2n | 20n | 75mav |
Calculating the Current Purchase Price
The current purchase price is calculated with the following formula:
El Clásico
available_stock | max_price | current_purchase_price |
---|---|---|
50n | 50mav | 1mav |
20n | 50mav | 2.5mav |
5n | 50mav | 10mav |
Especial del chef
available_stock | max_price | current_purchase_price |
---|---|---|
20n | 75mav | 3.75mav |
10n | 75mav | 7.5mav |
5n | 75mav | 15mav |
Draft a first contract
Designing the Taco Shop's Contract Storage
First think to do when you create a smart contract is
think about what gonna be stored onto it.
We know that Pedro's Taco Shop serves two kinds of tacos, so we will
need to manage stock individually, per kind. Let us define a type,
that will keep the stock
& max_price
per kind in a record with two
fields. Additionally, we will want to combine our taco_supply
type
into a map, consisting of the entire offer of Pedro's shop.
Taco shop's storage
Now that the storage is defined, let's interact with it.
Selling the Tacos for Free
Create your first entrypoint buy_taco
which is doing nothing for now :
It's already possible to compile your contract by running :
To avoid warning at compilation, change
taco_kind_index
into_taco_kind_index
, it'll tell to the compiler that this variable is authorized to not be used.
A good practice is to scope your contract into a module.
We export
taco_shop_storage
to be accessible outside the module/namespace on the next section.
There is an impact onto the compilation, now you have to tell to the compiler which module it need to compile :
Populating our Storage
When deploying contract, it is crucial to provide a correct
initial storage value. In our case the storage is type-checked as
taco_shop_storage
, because the default storage is not directly used in the code,
we encourage to declare the type, if your storage mutate, your default_storage will be in error.
Reflecting Pedro's daily offer,
our storage's value will be defined as follows:
The storage value is a map with two bindings (entries) distinguished by their keys
1n
and2n
.
Out of curiosity, let's try to use LIGO compile storage
command compile this value down to Michelson.
Our initial storage record is compiled to a Michelson map { Elt 1 (Pair 50 50000000) ; Elt 2 (Pair 20 75000000) }
holding the current_stock
and max_prize
in as a pair.
Implement some logic
Decreasing current_stock
when a Taco is Sold
In order to decrease the stock in our contract's storage for a specific taco kind, a few things needs to happen:
- retrieve the
taco_kind
from our storage, based on thetaco_kind_index
provided; - subtract the
taco_kind.current_stock
by1n
; - we can find the absolute value of the subtraction above by
calling
abs
(otherwise we would be left with anint
); - update the storage, and return it.
Making Sure We Get Paid for Our Tacos
In order to make Pedro's taco shop profitable, he needs to stop giving
away tacos for free. When a contract is invoked via a transaction, an
amount of mavzies to be sent can be specified as well. This amount is
accessible within LIGO as Mavryk.get_amount
.
To make sure we get paid, we will:
- calculate a
current_purchase_price
based on the equation specified earlier - check if the sent amount matches the
current_purchase_price
:- if not, then our contract will fail (
failwith
) - otherwise, stock for the given
taco_kind
will be decreased and the payment accepted
- if not, then our contract will fail (
Now let's test our function against a few inputs using the LIGO test framework. For that, we will have another file in which will describe our test:
Let's break it down a little bit:
- we include the file corresponding to the smart contract we want to test;
- we define
assert_string_failure
, a function reading a transfer result and testing against a failure. It also compares the failing data - here, a string - to what we expect it to be; test
is actually performing the tests: Originates the taco-shop contract; purchasing a Taco with 1mav and checking that the stock has been updated ; attempting to purchase a Taco with 2mav and trying to purchase an unregistered Taco. An auxiliary function to check equality of values on maps is defined.
checkout the reference page for a more detailed description of the Test API
Now it is time to use the LIGO command test
. It will evaluate our
smart contract and print the result value of those entries that start
with "test"
:
The test passed ! That's it - Pedro can now sell tacos on-chain, thanks to Mavryk & LIGO.
💰 Bonus: Accepting Tips above the Taco Purchase Price
If you would like to accept tips in your contract, simply change the following line, depending on your preference.
Without tips
With tips