<liclass="toctree-l2"><aclass="reference internal"href="#how-multi-party-transactions-are-constructed-and-transmitted">How multi-party transactions are constructed and transmitted</a></li>
discuss in the next tutorial). Clauses help reduce tedious boilerplate, but it’s worth understanding how a
contract is built without them before starting.</p>
<p>You can see the full Kotlin version of this contract in the code as <codeclass="docutils literal"><spanclass="pre">CommercialPaperLegacy</span></code>. The code in this
tutorial is available in both Kotlin and Java. You can quickly switch between them to get a feeling for how
Kotlin syntax works.</p>
<divclass="section"id="where-to-put-your-code">
<h2>Where to put your code<aclass="headerlink"href="#where-to-put-your-code"title="Permalink to this headline">¶</a></h2>
<p>A CorDapp is a collection of contracts, state definitions, protocols and other ways to extend the server. To create
one you would just create a Java-style project as normal, with your choice of build system (Maven, Gradle, etc).
Then add a dependency on <codeclass="docutils literal"><spanclass="pre">com.r3corda:core:0.X</span></code> where X is the milestone number you are depending on. The core
module defines the base classes used in this tutorial.</p>
<p>A smart contract is a class that implements the <codeclass="docutils literal"><spanclass="pre">Contract</span></code> interface. This can be either implemented directly, or
<p>Every contract must have at least a <codeclass="docutils literal"><spanclass="pre">getLegalContractReference()</span></code> and a <codeclass="docutils literal"><spanclass="pre">verify()</span></code> method. In Kotlin we express
a getter without a setter as an immutable property (val). The <em>legal contract reference</em> is supposed to be a hash
of a document that describes the legal contract and may take precedence over the code, in case of a dispute.</p>
<p>We define a class that implements the <codeclass="docutils literal"><spanclass="pre">ContractState</span></code> interface.</p>
<p>The <codeclass="docutils literal"><spanclass="pre">ContractState</span></code> interface requires us to provide a <codeclass="docutils literal"><spanclass="pre">getContract</span></code> method that returns an instance of the
contract class itself. In future, this will change to support dynamic loading of contracts with versioning
and signing constraints, but for now this is how it’s written.</p>
<li><codeclass="docutils literal"><spanclass="pre">issuance</span></code>, a reference to a specific piece of commercial paper issued by some party.</li>
<li><codeclass="docutils literal"><spanclass="pre">owner</span></code>, the public key of the current owner. This is the same concept as seen in Bitcoin: the public key has no
<li><codeclass="docutils literal"><spanclass="pre">faceValue</span></code>, an <codeclass="docutils literal"><spanclass="pre">Amount<Issued<Currency>></span></code>, which wraps an integer number of pennies and a currency that is
specific to some issuer (e.g. a regular bank, a central bank, etc). You can read more about this very common
type in <aclass="reference internal"href="transaction-data-types.html"><spanclass="doc">Data types</span></a>.</li>
<li><codeclass="docutils literal"><spanclass="pre">maturityDate</span></code>, an <aclass="reference external"href="https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html">Instant</a>, which is a type
from the Java 8 standard time library. It defines a point on the timeline.</li>
</ul>
<p>States are immutable, and thus the class is defined as immutable as well. The <codeclass="docutils literal"><spanclass="pre">data</span></code> modifier in the Kotlin version
causes the compiler to generate the equals/hashCode/toString methods automatically, along with a copy method that can
be used to create variants of the original object. Data classes are similar to case classes in Scala, if you are
familiar with that language. The <codeclass="docutils literal"><spanclass="pre">withoutOwner</span></code> method uses the auto-generated copy method to return a version of
the state with the owner public key blanked out: this will prove useful later.</p>
<p>We define a simple grouping interface or static class, this gives us a type that all our commands have in common,
then we go ahead and create three commands: <codeclass="docutils literal"><spanclass="pre">Move</span></code>, <codeclass="docutils literal"><spanclass="pre">Redeem</span></code>, <codeclass="docutils literal"><spanclass="pre">Issue</span></code>. <codeclass="docutils literal"><spanclass="pre">TypeOnlyCommandData</span></code> is a helpful utility
for the case when there’s no data inside the command; only the existence matters. It defines equals and hashCode
such that any instances always compare equal and hash to the same value.</p>
<p>We start by using the <codeclass="docutils literal"><spanclass="pre">groupStates</span></code> method, which takes a type and a function. State grouping is a way of ensuring
your contract can handle multiple unrelated states of the same type in the same transaction, which is needed for
splitting/merging of assets, atomic swaps and so on. More on this next.</p>
<p>The second line does what the code suggests: it searches for a command object that inherits from the
<codeclass="docutils literal"><spanclass="pre">CommercialPaper.Commands</span></code> supertype, and either returns it, or throws an exception if there’s zero or more than one
<p>The <codeclass="docutils literal"><spanclass="pre">TransactionForContract.groupStates</span></code> method handles this logic for us: firstly, it selects only states of the
So we just use a copy of the state minus the owner field as the grouping key.</p>
<p>Here are some code examples:</p>
<divclass="codeset container">
<divclass="highlight-kotlin"><divclass="highlight"><pre><span></span>// Type of groups is List<InOutGroup<State, Pair<PartyReference, Currency>>>
val groups = tx.groupStates() { it: Cash.State -> Pair(it.deposit, it.amount.currency) }
<p>The <codeclass="docutils literal"><spanclass="pre">groupStates</span></code> call uses the provided function to calculate a “grouping key”. All states that have the same
grouping key are placed in the same group. A grouping key can be anything that implements equals/hashCode, but it’s
always an aggregate of the fields that shouldn’t change between input and output. In the above example we picked the
fields we wanted and packed them into a <codeclass="docutils literal"><spanclass="pre">Pair</span></code>. It returns a list of <codeclass="docutils literal"><spanclass="pre">InOutGroup</span></code>, which is just a holder for the
inputs, outputs and the key that was used to define the group. In the Kotlin version we unpack these using destructuring
to get convenient access to the inputs, the outputs, the deposit data and the currency. The Java version is more
verbose, but equivalent.</p>
<p>The rules can then be applied to the inputs and outputs as if it were a single transaction. A group may have zero
inputs or zero outputs: this can occur when issuing assets onto the ledger, or removing them.</p>
<p>In this example, we do it differently and use the state class itself as the aggregator. We just
blank out fields that are allowed to change, making the grouping key be “everything that isn’t that”:</p>
<p>For large states with many fields that must remain constant and only one or two that are really mutable, it’s often
easier to do things this way than to specifically name each field that must stay the same. The <codeclass="docutils literal"><spanclass="pre">withoutOwner</span></code> function
here simply returns a copy of the object but with the <codeclass="docutils literal"><spanclass="pre">owner</span></code> field set to <codeclass="docutils literal"><spanclass="pre">NullPublicKey</span></code>, which is just a public key
of all zeros. It’s invalid and useless, but that’s OK, because all we’re doing is preventing the field from mattering
<spanclass="s">"the transaction is signed by the owner of the CP"</span><spanclass="k">by</span><spanclass="p">(</span><spanclass="n">input</span><spanclass="p">.</span><spanclass="n">owner</span><spanclass="k">in</span><spanclass="n">command</span><spanclass="p">.</span><spanclass="n">signers</span><spanclass="p">)</span>
<spanclass="s">"the state is propagated"</span><spanclass="k">by</span><spanclass="p">(</span><spanclass="n">group</span><spanclass="p">.</span><spanclass="n">outputs</span><spanclass="p">.</span><spanclass="n">size</span><spanclass="p">==</span><spanclass="m">1</span><spanclass="p">)</span>
<spanclass="k">val</span><spanclass="py">time</span><spanclass="p">=</span><spanclass="n">timestamp</span><spanclass="o">?.</span><spanclass="n">after</span><spanclass="o">?:</span><spanclass="k">throw</span><spanclass="n">IllegalArgumentException</span><spanclass="p">(</span><spanclass="s">"Redemptions must be timestamped"</span><spanclass="p">)</span>
<spanclass="s">"the paper must have matured"</span><spanclass="k">by</span><spanclass="p">(</span><spanclass="n">time</span><spanclass="p">>=</span><spanclass="n">input</span><spanclass="p">.</span><spanclass="n">maturityDate</span><spanclass="p">)</span>
<spanclass="s">"the received amount equals the face value"</span><spanclass="k">by</span><spanclass="p">(</span><spanclass="n">received</span><spanclass="p">==</span><spanclass="n">input</span><spanclass="p">.</span><spanclass="n">faceValue</span><spanclass="p">)</span>
<spanclass="s">"the paper must be destroyed"</span><spanclass="k">by</span><spanclass="n">outputs</span><spanclass="p">.</span><spanclass="n">isEmpty</span><spanclass="p">()</span>
<spanclass="s">"the transaction is signed by the owner of the CP"</span><spanclass="k">by</span><spanclass="p">(</span><spanclass="n">input</span><spanclass="p">.</span><spanclass="n">owner</span><spanclass="k">in</span><spanclass="n">command</span><spanclass="p">.</span><spanclass="n">signers</span><spanclass="p">)</span>
<spanclass="k">val</span><spanclass="py">time</span><spanclass="p">=</span><spanclass="n">timestamp</span><spanclass="o">?.</span><spanclass="n">before</span><spanclass="o">?:</span><spanclass="k">throw</span><spanclass="n">IllegalArgumentException</span><spanclass="p">(</span><spanclass="s">"Issuances must be timestamped"</span><spanclass="p">)</span>
<spanclass="s">"output states are issued by a command signer"</span><spanclass="k">by</span><spanclass="p">(</span><spanclass="n">output</span><spanclass="p">.</span><spanclass="n">issuance</span><spanclass="p">.</span><spanclass="n">party</span><spanclass="p">.</span><spanclass="n">owningKey</span><spanclass="k">in</span><spanclass="n">command</span><spanclass="p">.</span><spanclass="n">signers</span><spanclass="p">)</span>
<spanclass="s">"output values sum to more than the inputs"</span><spanclass="k">by</span><spanclass="p">(</span><spanclass="n">output</span><spanclass="p">.</span><spanclass="n">faceValue</span><spanclass="p">.</span><spanclass="n">quantity</span><spanclass="p">></span><spanclass="m">0</span><spanclass="p">)</span>
<spanclass="s">"the maturity date is not in the past"</span><spanclass="k">by</span><spanclass="p">(</span><spanclass="n">time</span><spanclass="p"><</span><spanclass="n">output</span><spanclass="p">.</span><spanclass="n">maturityDate</span><spanclass="p">)</span>
<spanclass="s">"can't reissue an existing state"</span><spanclass="k">by</span><spanclass="n">inputs</span><spanclass="p">.</span><spanclass="n">isEmpty</span><spanclass="p">()</span>
<divclass="highlight-java"><divclass="highlight"><pre><span></span><spanclass="n">Timestamp</span><spanclass="n">time</span><spanclass="o">=</span><spanclass="n">tx</span><spanclass="o">.</span><spanclass="na">getTimestamp</span><spanclass="o">();</span><spanclass="c1">// Can be null/missing.</span>
<spanclass="n">checkState</span><spanclass="o">(</span><spanclass="n">cmd</span><spanclass="o">.</span><spanclass="na">getSigners</span><spanclass="o">().</span><spanclass="na">contains</span><spanclass="o">(</span><spanclass="n">input</span><spanclass="o">.</span><spanclass="na">getOwner</span><spanclass="o">()),</span><spanclass="s">"the transaction is signed by the owner of the CP"</span><spanclass="o">);</span>
<spanclass="n">checkState</span><spanclass="o">(</span><spanclass="n">outputs</span><spanclass="o">.</span><spanclass="na">size</span><spanclass="o">()</span><spanclass="o">==</span><spanclass="mi">1</span><spanclass="o">,</span><spanclass="s">"the state is propagated"</span><spanclass="o">);</span>
<spanclass="n">checkNotNull</span><spanclass="o">(</span><spanclass="n">timem</span><spanclass="s">"must be timestamped"</span><spanclass="o">);</span>
<spanclass="n">checkState</span><spanclass="o">(</span><spanclass="n">received</span><spanclass="o">.</span><spanclass="na">equals</span><spanclass="o">(</span><spanclass="n">input</span><spanclass="o">.</span><spanclass="na">getFaceValue</span><spanclass="o">()),</span><spanclass="s">"received amount equals the face value"</span><spanclass="o">);</span>
<spanclass="n">checkState</span><spanclass="o">(</span><spanclass="n">t</span><spanclass="o">.</span><spanclass="na">isBefore</span><spanclass="o">(</span><spanclass="n">input</span><spanclass="o">.</span><spanclass="na">getMaturityDate</span><spanclass="o">(),</span><spanclass="s">"the paper must have matured"</span><spanclass="o">);</span>
<spanclass="n">checkState</span><spanclass="o">(</span><spanclass="n">outputs</span><spanclass="o">.</span><spanclass="na">isEmpty</span><spanclass="o">(),</span><spanclass="s">"the paper must be destroyed"</span><spanclass="o">);</span>
verify we didn’t forget to check if it’s missing. Unfortunately due to the need for smooth Java interop, this
check won’t happen if we write e.g. <codeclass="docutils literal"><spanclass="pre">someDate</span><spanclass="pre">></span><spanclass="pre">time</span></code>, it has to be <codeclass="docutils literal"><spanclass="pre">time</span><spanclass="pre"><</span><spanclass="pre">someDate</span></code>. So it’s good practice to
always write the transaction timestamp first.</p>
</div>
<p>The first line (first three lines in Java) impose a requirement that there be a single piece of commercial paper in
this group. We do not allow multiple units of CP to be split or merged even if they are owned by the same owner. The
<codeclass="docutils literal"><spanclass="pre">single()</span></code> method is a static <em>extension method</em> defined by the Kotlin standard library: given a list, it throws an
exception if the list size is not 1, otherwise it returns the single item in that list. In Java, this appears as a
is straightforward: we are simply using the <codeclass="docutils literal"><spanclass="pre">Preconditions.checkState</span></code> method from Guava. The Kotlin version looks a little odd: we have a <em>requireThat</em> construct that looks like it’s
built into the language. In fact <em>requireThat</em> is an ordinary function provided by the platform’s contract API. Kotlin
supports the creation of <em>domain specific languages</em> through the intersection of several features of the language, and
we use it here to support the natural listing of requirements. To see what it compiles down to, look at the Java version.
Each <codeclass="docutils literal"><spanclass="pre">"string"</span><spanclass="pre">by</span><spanclass="pre">(expression)</span></code> statement inside a <codeclass="docutils literal"><spanclass="pre">requireThat</span></code> turns into an assertion that the given expression is
true, with an <codeclass="docutils literal"><spanclass="pre">IllegalStateException</span></code> being thrown that contains the string if not. It’s just another way to write out a regular
assertion, but with the English-language requirement being put front and center.</p>
<p>Next, we take one of two paths, depending on what the type of the command object is.</p>
<p>If the command is a <codeclass="docutils literal"><spanclass="pre">Move</span></code> command, then we simply verify that the output state is actually present: a move is not
allowed to delete the CP from the ledger. The grouping logic already ensured that the details are identical and haven’t
been changed, save for the public key of the owner.</p>
<p>If the command is a <codeclass="docutils literal"><spanclass="pre">Redeem</span></code> command, then the requirements are more complex:</p>
<olclass="arabic simple">
<li>We want to see that the face value of the CP is being moved as a cash claim against some party, that is, the
issuer of the CP is really paying back the face value.</li>
<li>The transaction must be happening after the maturity date.</li>
<li>The commercial paper must <em>not</em> be propagated by this transaction: it must be deleted, by the group having no
output state. This prevents the same CP being considered redeemable multiple times.</li>
<p>To calculate how much cash is moving, we use the <codeclass="docutils literal"><spanclass="pre">sumCashBy</span></code> utility function. Again, this is an extension function,
so in Kotlin code it appears as if it was a method on the <codeclass="docutils literal"><spanclass="pre">List<Cash.State></span></code> type even though JDK provides no such
method. In Java we see its true nature: it is actually a static method named <codeclass="docutils literal"><spanclass="pre">CashKt.sumCashBy</span></code>. This method simply
returns an <codeclass="docutils literal"><spanclass="pre">Amount</span></code> object containing the sum of all the cash states in the transaction outputs that are owned by
that given public key, or throws an exception if there were no such states <em>or</em> if there were different currencies
represented in the outputs! So we can see that this contract imposes a limitation on the structure of a redemption
transaction: you are not allowed to move currencies in the same transaction that the CP does not involve. This
limitation could be addressed with better APIs, if it were to be a real limitation.</p>
<p>Finally, we support an <codeclass="docutils literal"><spanclass="pre">Issue</span></code> command, to create new instances of commercial paper on the ledger. It likewise
enforces various invariants upon the issuance.</p>
As contract code is just a regular Java function you could write out the logic entirely by hand in the usual
manner. But this would be inconvenient, and then you’d get bored of writing tests and that would be bad: you
might be tempted to skip a few.</p>
<p>To make contract testing more convenient Corda provides a language-like API for both Kotlin and Java that lets
you easily construct chains of transactions and verify that they either pass validation, or fail with a particular
error message.</p>
<p>Testing contracts with this domain specific language is covered in the separate tutorial, <aclass="reference internal"href="tutorial-test-dsl.html"><spanclass="doc">Writing a contract test</span></a>.</p>
<h2>Adding a generation API to your contract<aclass="headerlink"href="#adding-a-generation-api-to-your-contract"title="Permalink to this headline">¶</a></h2>
<p>Contract classes <strong>must</strong> provide a verify function, but they may optionally also provide helper functions to simplify
their usage. A simple class of functions most contracts provide are <em>generation functions</em>, which either create or
modify a transaction to perform certain actions (an action is normally mappable 1:1 to a command, but doesn’t have to
be so).</p>
<p>Generation may involve complex logic. For example, the cash contract has a <codeclass="docutils literal"><spanclass="pre">generateSpend</span></code> method that is given a set of
cash states and chooses a way to combine them together to satisfy the amount of money that is being sent. In the
immutable-state model that we are using ledger entries (states) can only be created and deleted, but never modified.
Therefore to send $1200 when we have only $900 and $500 requires combining both states together, and then creating
two new output states of $1200 and $200 back to ourselves. This latter state is called the <em>change</em> and is a concept
that should be familiar to anyone who has worked with Bitcoin.</p>
<p>As another example, we can imagine code that implements a netting algorithm may generate complex transactions that must
be signed by many people. Whilst such code might be too big for a single utility method (it’d probably be sized more
like a module), the basic concept is the same: preparation of a transaction using complex logic.</p>
<p>For our commercial paper contract however, the things that can be done with it are quite simple. Let’s start with
bookkeeping/reference numbers that we may require. The reference field is an ideal place to put (for example) a
join key. Then the face value of the paper, and the maturity date. It returns a <codeclass="docutils literal"><spanclass="pre">TransactionBuilder</span></code>.
A <codeclass="docutils literal"><spanclass="pre">TransactionBuilder</span></code> is one of the few mutable classes the platform provides. It allows you to add inputs,
outputs and commands to it and is designed to be passed around, potentially between multiple contracts.</p>
<pclass="last">Generation methods should ideally be written to compose with each other, that is, they should take a
<codeclass="docutils literal"><spanclass="pre">TransactionBuilder</span></code> as an argument instead of returning one, unless you are sure it doesn’t make sense to
combine this type of transaction with others. In this case, issuing CP at the same time as doing other things
would just introduce complexity that isn’t likely to be worth it, so we return a fresh object each time: instead,
an issuer should issue the CP (starting out owned by themselves), and then sell it in a separate transaction.</p>
</div>
<p>The function we define creates a <codeclass="docutils literal"><spanclass="pre">CommercialPaper.State</span></code> object that mostly just uses the arguments we were given,
but it fills out the owner field of the state to be the same public key as the issuing party.</p>
<p>The returned partial transaction has a <codeclass="docutils literal"><spanclass="pre">Command</span></code> object as a parameter. This is a container for any object
that implements the <codeclass="docutils literal"><spanclass="pre">CommandData</span></code> interface, along with a list of keys that are expected to sign this transaction. In this case,
<p>The <codeclass="docutils literal"><spanclass="pre">TransactionBuilder</span></code> has a convenience <codeclass="docutils literal"><spanclass="pre">withItems</span></code> method that takes a variable argument list. You can pass in
any <codeclass="docutils literal"><spanclass="pre">StateAndRef</span></code> (input), <codeclass="docutils literal"><spanclass="pre">ContractState</span></code> (output) or <codeclass="docutils literal"><spanclass="pre">Command</span></code> objects and it’ll build up the transaction
<p>There’s one final thing to be aware of: we ask the caller to select a <em>notary</em> that controls this state and
prevents it from being double spent. You can learn more about this topic in the <aclass="reference internal"href="consensus.html"><spanclass="doc">Consensus model</span></a> article.</p>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">For now, don’t worry about how to pick a notary. More infrastructure will come later to automate this
<p>Here, the method takes a pre-existing <codeclass="docutils literal"><spanclass="pre">TransactionBuilder</span></code> and adds to it. This is correct because typically
you will want to combine a sale of CP atomically with the movement of some other asset, such as cash. So both
generate methods should operate on the same transaction. You can see an example of this being done in the unit tests
for the commercial paper contract.</p>
<p>The paper is given to us as a <codeclass="docutils literal"><spanclass="pre">StateAndRef<CommercialPaper.State></span></code> object. This is exactly what it sounds like:
a small object that has a (copy of) a state object, and also the (txhash, index) that indicates the location of this
an exception is thrown. Then we add the paper itself as an input, but, not an output (as we wish to remove it
from the ledger). Finally, we add a Redeem command that should be signed by the owner of the commercial paper.</p>
<divclass="admonition warning">
<pclass="first admonition-title">Warning</p>
<pclass="last">The amount we pass to the <codeclass="docutils literal"><spanclass="pre">generateSpend</span></code> function has to be treated first with <codeclass="docutils literal"><spanclass="pre">withoutIssuer</span></code>.
This reflects the fact that the way we handle issuer constraints is still evolving; the commercial paper
contract requires payment in the form of a currency issued by a specific party (e.g. the central bank,
or the issuers own bank perhaps). But the wallet wants to assemble spend transactions using cash states from
any issuer, thus we must strip it here. This represents a design mismatch that we will resolve in future
versions with a more complete way to express issuer constraints.</p>
<p>A <codeclass="docutils literal"><spanclass="pre">TransactionBuilder</span></code> is not by itself ready to be used anywhere, so first, we must convert it to something that
is recognised by the network. The most important next step is for the participating entities to sign it using the
<codeclass="docutils literal"><spanclass="pre">signWith()</span></code> method. This takes a keypair, serialises the transaction, signs the serialised form and then stores the
signature inside the <codeclass="docutils literal"><spanclass="pre">TransactionBuilder</span></code>. Once all parties have signed, you can call <codeclass="docutils literal"><spanclass="pre">TransactionBuilder.toSignedTransaction()</span></code>
<h2>How multi-party transactions are constructed and transmitted<aclass="headerlink"href="#how-multi-party-transactions-are-constructed-and-transmitted"title="Permalink to this headline">¶</a></h2>
<p>OK, so now we know how to define the rules of the ledger, and we know how to construct transactions that satisfy
those rules ... and if all we were doing was maintaining our own data that might be enough. But we aren’t: Corda
is about keeping many different parties all in sync with each other.</p>
<p>In a classical blockchain system all data is transmitted to everyone and if you want to do something fancy, like
a multi-party transaction, you’re on your own. In Corda data is transmitted only to parties that need it and
multi-party transactions are a way of life, so we provide lots of support for managing them.</p>
<p>You can learn how transactions are moved between peers and taken through the build-sign-notarise-broadcast
process in a separate tutorial, <aclass="reference internal"href="protocol-state-machines.html"><spanclass="doc">Protocol state machines</span></a>.</p>
world, and (code) contracts as imposing logical relations on how facts combine to produce new facts. Alternatively
you can imagine that states are like rows in a relational database and contracts are like stored procedures and
relational constraints.</p>
<p>When writing a contract that handles deal-like entities rather than asset-like entities, you may wish to refer
to “<aclass="reference internal"href="contract-irs.html"><spanclass="doc">Interest Rate Swaps</span></a>” and the accompanying source code. Whilst all the concepts are the same, deals are
typically not splittable or mergeable and thus you don’t have to worry much about grouping of states.</p>
<h2>Making things happen at a particular time<aclass="headerlink"href="#making-things-happen-at-a-particular-time"title="Permalink to this headline">¶</a></h2>
<p>It would be nice if you could program your node to automatically redeem your commercial paper as soon as it matures.
Corda provides a way for states to advertise scheduled events that should occur in future. Whilst this information
is by default ignored, if the corresponding <em>Cordapp</em> is installed and active in your node, and if the state is
considered relevant by your wallet (e.g. because you own it), then the node can automatically begin the process
of creating a transaction and taking it through the life cycle. You can learn more about this in the article
<p>It is typical for slightly different contracts to have lots of common logic that can be shared. For example, the
concept of being issued, being exited and being upgraded are all usually required in any contract. Corda calls these
frequently needed chunks of logic “clauses”, and they can simplify development considerably.</p>
<p>Clauses and how to use them are addressed in the next tutorial, “<aclass="reference internal"href="tutorial-contract-clauses.html"><spanclass="doc">Writing a contract using clauses</span></a>”.</p>
<ahref="tutorial-contract-clauses.html"class="btn btn-neutral float-right"title="Writing a contract using clauses"accesskey="n">Next <spanclass="fa fa-arrow-circle-right"></span></a>
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
