Skip to content

DO NOT MERGE: ts2 - split AmuletAllocation and AmuletAllocationV2 and polish V2#4337

Draft
meiersi-da wants to merge 47 commits intomeiersi/ts2/rebase/copy-and-rename-onlyfrom
meiersi/ts2/rebase/poc-separate-amuletallocations
Draft

DO NOT MERGE: ts2 - split AmuletAllocation and AmuletAllocationV2 and polish V2#4337
meiersi-da wants to merge 47 commits intomeiersi/ts2/rebase/copy-and-rename-onlyfrom
meiersi/ts2/rebase/poc-separate-amuletallocations

Conversation

@meiersi-da
Copy link
Contributor

Pull Request Checklist

Cluster Testing

  • If a cluster test is required, comment /cluster_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
  • If a hard-migration test is required (from the latest release), comment /hdm_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.

PR Guidelines

  • Include any change that might be observable by our partners or affect their deployment in the release notes.
  • Specify fixed issues with Fixes #n, and mention issues worked on using #n
  • Include a screenshot for frontend-related PRs - see README or use your favorite screenshot tool

Merge Guidelines

  • Make the git commit message look sensible when squash-merging on GitHub (most likely: just copy your PR description).

@meiersi-da meiersi-da marked this pull request as draft March 9, 2026 16:30
@meiersi-da meiersi-da changed the base branch from meiersi/ts2/rebase/poc-provider-authz-on-tf to meiersi/ts2/rebase/copy-and-rename-only March 10, 2026 05:27
@meiersi-da meiersi-da force-pushed the meiersi/ts2/rebase/poc-separate-amuletallocations branch from 8e1db7f to cf7bdaf Compare March 10, 2026 06:07
@meiersi-da meiersi-da changed the base branch from meiersi/ts2/rebase/copy-and-rename-only to meiersi/ts2/rebase/poc-provider-authz-on-tf March 11, 2026 07:13
@meiersi-da meiersi-da changed the base branch from meiersi/ts2/rebase/poc-provider-authz-on-tf to meiersi/ts2/rebase/copy-and-rename-only March 13, 2026 13:55
Copy link
Contributor Author

@meiersi-da meiersi-da left a comment

Choose a reason for hiding this comment

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

@bame-da: I think the code for allocations is ready for an alignment review. The base for this PR is a branch where the V2 files are a pure copy and rename of the V1 versions.

I've added comments tagged with @bame-da to guide your attention, so you don't end up reviewing WIP material. I focused on polishing the AllocationV2 API together with its implementation in AmuletAllocation and AmuletAllocationV2 based on helper functions in a split-up version of your UtilsV2 module.

I'm looking for two things:

  1. double-checking our alignment on the API and its implementation
  2. help for making the remaining few design decisions (mostly how to use the actors pattern, and whether to switch away from the settlementVersion)

Once we have the decisions, I'll implement and smoke test them on the AlocationV2 code, so that I can then reach out to Moritz for a review.

Once that's done, I'll pull through the design through all APIs, and get the PR into a state, where we can ask app builders and registry operators to start implementing PoC's against the new APIs on their side.

--
-- Registries that require joint authorization for a withdrawal to complete SHOULD
-- set this to the empty list, and provide a registry specific UI to
-- initiate and complete the withdrawal.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note: I'm not sure about this construction, it seems a bit too ad-hoc.

I'm though also wary about the generic construction where the possible actors for every choice are encoded in the view, as that requires a type of the form Map ActionId [[Party]], which can become large for rich action graphs.

--
-- Additional versions may defined in future extensions of the token standard.
--
-- FIXME: consider whether we can replace this ^^ in favor of `extraSettlementAuthorizers`
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will give this a try. Left it as-is for now to get a first version into a reviewable state.

allocation_withdrawExtraObservers _arg = []

allocation_withdrawImpl self arg@(V2.Allocation_Withdraw{..}) = do
archive self
Copy link
Contributor Author

Choose a reason for hiding this comment

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

TODO: simplify the check using the canWithdraw information

feeLeg


-- | Test that a DvP settlement of an OTC trade works when using Amulet via the token standard.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bame-da: mixed version settlement worth reviewing together with the code used in the TradingAppV2 to manage the actors.

@@ -1,18 +1,30 @@
-- Copyright (c) 2024 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
-- SPDX-License-Identifier: Apache-2.0
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bame-da: worth reviewing in full. Apart from the FIXME's the API here is polished.

I expect that we want to get rid of the settlementVersion though; and I expect that we want to make a more consistent decision wrt actors vs. controller overrides.

@@ -6,8 +6,6 @@
-- for the purpose of settling a DvP or a payment as part of an app's workflow.
module Splice.Api.Token.AllocationRequestV2 where
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bame-da: ready for review, but nothing surprising in here.

-- Copyright (c) 2024 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
-- SPDX-License-Identifier: Apache-2.0

-- | Interfaces to enable wallets to instruct the registry to create allocations.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bame-da: this module is still a bit WIP. The main construction site is how to deal best with the actors pattern and different authorization policies by different registries. I don't think it's going to be terribly difficult. Just didn't have time to build a convincing solution proposal.

I suggest we first align on AllocationV2 + mixed version settlement + allocation request, before we finish this one.

return [ reqView | (_, Some reqView) <- reqs ]


-- | Accept the allocation request by authorizing the transfer of all its requested legs.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bame-da: this is how I expect wallets to accept allocation requests. Worth reviewing to check alignment.

I haven't yet built the analoguous function for V1 requests. I expect it will work by creating one v1 allocation for every single leg.

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.

1 participant