Signing constraints

An important aspect of any CorDapp is the permissioning model, in other words who needs to sign which transactions. In Corda, the required signers are attached to the transaction’s Command. This can be mirrored in the CDL Smart Contract view by including the require signer in brackets underneath the Command on the Path constraint.

The signer is usually defined in terms of some property in the State. You would not usually specify that a particular Party, say PartyA must sign, instead you would specify that the party referenced in the seller property needs to sign, which may on some instances of the state happen to be PartyA.

It is also important to specify which state you are referencing for the property. Properties can change between the input state and the output state, you need to specify which.

In the Agreement example, when performing a Repropose command, the output.proposer must sign, this may well be a different value from the input.proposer.

In some use cases signing constraints can get more complicated. A deliberately convoluted example might be: The buyer or seller must sign unless an escrow agent has presented a state of type X before the 3rd Tuesday in May in which case two of three appointed arbiters can sign. If this is the case, it’s best to use a separate callout to explain the constraint in more detail.

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.