Consider a case of assets exchange. Assume we already have procedures functionality (a procedure - is an ISI stored in an Asset, that can be called by demand. One may call it a smart-contract). The ‘exchange’ procedure is owned by an account that no one has access to, otherwise the "contract" may be violated. This procedure performs the following actions with the following algorithm:
- Wait for an Asset transfer from a useran Account
- Get information about exchanging assets (base asset ID, target asset ID, exchange rate).
- Check that these assets exist and can be exchanged.
- Calculate the target currency amount by passing the retrieved exchange rate to the mathematical instruction as an argument
- Make a transfer by passing the calculated amount of the target currency, recipient account ID (that is, the user who made the transfer in step 1), and the target asset ID as an argument in the AssetTransfer ISI.
Let's assume that the passing of values as arguments is done through third-party assets. That is, one ISI writes the result to an asset-store, and the other reads from it.
Then, a few questions arise…
...
Requirements for this case are the following:
- To have the ability to pass exchange-related data like 'exchanging asset ID' and etc. to the algorithm (from asset-store, for example).
- To be able to manipulate the given data. For example, to calculate the exchanged currency amount.
- To store new data. For example, to store the calculated amount.
- To load saved data and pass it as an argument for an ISI. E.g. passing the calculated amount to the `TransferAsset` ISI.
- To have a guarantee that all the stored data is consistent, so the user would not have to verify all the data by itself.
Additional requirements for the algorithm:
- It should be persisted, so no one could change the order of the instructions.
- It should be guaranteed that the creator of the algorithm is not permitted to call these instructions by itself.