Skip to content

[Draft] Auto reassignment fail#2046

Draft
jarekr-da wants to merge 12 commits into
wiktor/multisync-examplefrom
jarekr/multisync-example_no_reassign
Draft

[Draft] Auto reassignment fail#2046
jarekr-da wants to merge 12 commits into
wiktor/multisync-examplefrom
jarekr/multisync-example_no_reassign

Conversation

@jarekr-da

Copy link
Copy Markdown
Contributor

No description provided.

Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
stakeholder, and indeed the _explicit_ `reassign` submitted by Bob always
worked. The blocker is the **`TokenRules` factory**, whose only stakeholder is
`admin`. With a **separate `TokenAdmin` party**, the submitter (Bob) is **not** a
stakeholder of `TokenRules`, so Canton refuses to reassign it automatically.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the unreassignability of the TokenRules is why I'm pushing for guidelines where the workflows tell the token standard registry what the target synchronizer is. See this conversation: #1622 (review)

For that to work cleanly we'll need a small amendment to the token standard off-ledger APIs. However, until then we can funnel the information in an additional field in the choiceArgument submitted to the factory endpoints; e.g. a top-level _targetSynchronizerId field, which you then parse in the TestTokenV1 registry handlers.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not understand this :-(
I tried to play around - but do not get how would this additional field help in fundamental problem, that contract cannot be reassigned automatically

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The trick is that the TestTokenV1 registry maintains TokenRules contract on every synchronizer it supports and selects the right one based on the communicated target synchronizer. This guarantees that TokenRules contracts never need to be reassigned by the client submitting a token standard action.

jarekr-da added 10 commits June 23, 2026 13:14
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Signed-off-by: jarekr-da <jaroslaw.ratajski@digitalasset.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants