diff --git a/plutus-book/doc/04-smartcont.adoc b/plutus-book/doc/04-smartcont.adoc index 33d039eb98a..4fcef5e2389 100644 --- a/plutus-book/doc/04-smartcont.adoc +++ b/plutus-book/doc/04-smartcont.adoc @@ -203,7 +203,7 @@ upon by both parties. These types of tokens can be tracked on a blockchain by a unique ID, that would be associated with an address, and thus its owner, similar to a regular ownership document. We will discuss how exactly such a unique ID -can be constructed in the extended UTxO model. +can be constructed in the extended UTxO model. == Loans @@ -221,6 +221,86 @@ if there is a party willing to risk the full value of the loan (interest included), and is not benefitting from the contract, why is this loan even necessary? -There is another approach to making loans into smart contracts as well. +There is another approach to building smart contract loans and variations thereof. +One may introduce a non-fungible token on the blockchain that the entity acquiring the loan +exchanges for the total value that must be paid to the lending party +(i.e. the money loaned plus interest). This would even allow the terms of a loan +to be renegotiated, perhaps changing the value of the loan token. +This a very promising approach for managing loans on a smart contract platform that +supports non-monetary tokens, provided there is some real-world legal assurance +to back up the lender in case of non-payment. == ACTUS + +ACTUS is an ongoing project started with the aim to define a taxonomy, or +classification, of all (or nearly all) financial contracts into a small +number of groups. Several major financial companies have come together +to create this common standard, including Ariadne, Deloitte, and Stevens Institute +of Technology. The project can be found at + +https://www.actusfrf.org/ + +A financial contract, as defined in Securities law, is + +* An arrangement that takes +the form of an individually +negotiated contract, agreement, or option to buy, sell, lend, swap, or +repurchase, or other similar individually negotiated transaction commonly +entered into by participants in the financial markets. + +ACTUS recognizes that there are two different ways to view financial contracts, +as described by two different disciplines: + +.ACTUS data standard +* The Data Standard defines a universal set of legal terms – or CT Attributes – +used as parameters throughout the different financial agreements. It is +implemented in form of a Data Dictionary with Attribute Applicability by +Contract Type. + +.ACTUS algorithmic standard +* The Algorithmic Standard defines the logic embedded in legal agreements that +eventually turn the contract terms into actual cash flows, or more generally +business events. + +Both standards have the tools to describe nearly all financial contracts, and +ACTUS aims to ensure that the semantics of what is described by both standards are +identical. +The ACTUS classification divides the contracts into groups by basic algorithmic structure. +For contracts within the same classification group, roughly the same +calculations are done to determine execution of the contract. The differences +between contracts within the same group are usually in the values of certain +parameters in the algorithm. A formal specification of the contracts within +each group is available on the ACTUS site. + +The reason we discuss the ACTUS taxonomy approach here is that +the idea of implementing ACTUS contracts in Plutus is very exciting both +conceptually as a major real-world practical advancement. From the ACTUS +website, + +[quote] +____ +"Recent financial crises laid bare serious shortcomings in risk management and +financial regulation. In retrospect, the lack of timely granular data reported +in a data standard capable of supporting financial analysis contributed much +to the crises. The ACTUS project aims to remedy this weakness by creating a +global standard for the consistent representation of financial instruments." +____ + +Financial contracts include things like futures, loans bonds, mortgages, etc. +In essence, financial contracts are contracts that only deal with the +transfer of money and promises made about future money transfers. +These types of contracts are influenced by outside events, like market values +of stocks, etc. They are also often the result of a real world change of ownership, +such a a mortgage would be for the purchase of a house. +However, there are two main types of tokens they deal with, + +* currency, +* and the contracts or financial products themselves (e.g. stocks or futures) + +This makes financial contracts perfect candidates for smart contract implementation. +Currency is already the superstar of the types of token that can be tracked by +the blockchain - Cardano is a cryptocurrency platform after all. Trading contracts +and financial products, +too, can be modeled on a ledger with smart contract support. +We are very excited to explore ways of representing all ACTUS contracts +as smart contract implementations in the upcoming chapters of this book. diff --git a/plutus-book/doc/09-extended.adoc b/plutus-book/doc/09-extended.adoc index 91b62cca4e0..2f3c604ae6c 100644 --- a/plutus-book/doc/09-extended.adoc +++ b/plutus-book/doc/09-extended.adoc @@ -187,7 +187,9 @@ Now, in order to prove that a transaction latexmath:[tx] is indeed authorized to locked by a validator script, the node doing the validation must apply a latexmath:[\mathsf{validateScript}] function to that validator script, and the three arguments above, which effectively is the computation applying the validator to the three arguments. -As pointed out earlier, the data and redeemer scripts can be very different types +It is necessary to use such a generic evaluator function here due to +the typing of the three scripts. +As pointed out in the <<_plutus_tx>> chapter, the data and redeemer scripts can be very different types of Plutus Core expressions generated by template Haskell, so all that is known to the generic latexmath:[\mathsf{validateScript}] function is that these are the three types of scripts. The validator itself, however, is expecting a term of the exact type it @@ -201,11 +203,12 @@ To summarize, the node computes where -* the validator latexmath:[vld] comes from the transaction itself and has -hash to the value of the address of the ledger UTxO entry the transaction is spending -* the data script latexmath:[dsc] is stored in the ledger UTxO entry the transaction -is spending -* the redeemer latexmath:[rdm] is the choice of action the wallet has (or its +* the validator latexmath:[vld] comes from the transaction itself and +hashes to the value equal to the address of the ledger UTxO entry the transaction is spending +* the data script latexmath:[dsc] is stored on the ledger and is associated +with the UTxO entry the transaction is spending (it can be looked up by this +entry as a key) +* the redeemer latexmath:[rdm] is the choice of action the wallet (or its owner) has made when generating the transaction, and comes directly from transaction data