Transaction input states are shown at the beginning of an arrow going into transaction boxes. You must ensure that an individual instance of a state is only ever shown once on the diagram, with input and output arrows linking it respectively to the transaction that created it, and the transaction that consumes it.
In this example, you can see that Bob has rejected Alice’s proposal. He does this by creating and signing a transaction which consumes the PROPOSED state and creates a REJECTED state that: rejects the transaction because he has Run out of bananas.
Continuing with the example, you can see that Bob has come up with a counter-proposal for One bag of grapes for £8. You can see that now Bob is the proposer, whereas Alice is the consenter in the new PROPOSED state and that he got to the PROPOSED state from a repropose command rather than a propose command.
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
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.