Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

“Sender Reference” capability #50

Open
pgrindean opened this issue May 3, 2019 · 2 comments
Open

“Sender Reference” capability #50

pgrindean opened this issue May 3, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@pgrindean
Copy link

pgrindean commented May 3, 2019

It is common practice that an operation initiator should be able to assign a reference to the transaction originated by his instruction.(see “Sender Reference”, “Originator Reference” in SWIFT messages standard)
For instance, to accommodate this requirement, the RedeemToken.InitiateRedeem flow could instantiate the TransactionBuilder object, and possibly add to it the reference states considered relevant before sending it to the RedeemToken.IssuerResponder counterparty flow which manages the Token States exit process. The reference states could be provisioned through an extra RedeemToken.InitiateRedeem constructor argument.

@roger-that-dev
Copy link

Thanks @pgrindean. Do you only need to only add reference data for redeeming, or do you need it for moves as well? Have you had a look at the https://github.com/corda/cash-issuer for how i did this? I added an additional state called a NodeTransaction which contains details of the redemption. This state is then used to help match the resulting cash payment from the issuer to the customer redeeming the cash states. We could do something like that ?

@pgrindean
Copy link
Author

pgrindean commented May 6, 2019

I think it's not unreasonable to conceive that the Token State transacting could have an external origin, i.e. an incoming "Order State" possibly intermediated by the Daemon, whose processing would initiate the MoveCash or the RedeemCash flows. It is this presumed original "Order State" which I'd like to be able to relate to the actual Token State transaction executed by the Issuer node. As long as the Token State transaction can be related to an external reference, possibly pointing to a prior Order State, I am not sure if it is still necessary that the actual Token State processing flow to originate extra states, as the RedeemCashHandler does. Instead, the Issuer node can register custom Token Transactions observers which can do any post-processing that is needed, e.g. instruct the cash system to move the collateral cash to the ordering customer, if the current Token State transaction was a redemption request.

@roger-that-dev roger-that-dev added the enhancement New feature or request label Nov 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants