ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-19 13:08:04 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Fixes a formatting issue.

Browse Source
This commit is contained in:
Joel Dudley 2017-10-02 09:09:16 +01:00 committed by GitHub
parent 2a1a9c9d20
commit f961412396
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/source/key-concepts-contract-constraints.rst
View File

@ -15,7 +15,7 @@ A typical constraint is the hash of the CorDapp JAR that contains the contract a
include constraints that require specific signers of the JAR, or both the signer and the hash. Constraints can be
specified when constructing a transaction; if unspecified, an automatic constraint is used.
``TransactionState``s have a ``constraint`` field that represents that state's attachment constraint. When a party
A ``TransactionState`` has a ``constraint`` field that represents that state's attachment constraint. When a party
constructs a ``TransactionState`` without specifying the constraint parameter a default value
(``AutomaticHashConstraint``) is used. This default will be automatically resolved to a specific
``HashAttachmentConstraint`` that contains the hash of the attachment which contains the contract of that
@ -80,8 +80,8 @@ attachment JAR. This allows for trusting of attachments from trusted entities.
Limitations
-----------
``AttachmentConstraint``s are verified by running the ``AttachmentConstraint.isSatisfiedBy`` method. When this is called
it is provided only the relevant attachment by the transaction that is verifying it.
An ``AttachmentConstraint`` is verified by running the ``AttachmentConstraint.isSatisfiedBy`` method. When this is
called it is provided only the relevant attachment by the transaction that is verifying it.
Testing
-------