DO NOT MERGE: ts2 - split AmuletAllocation and AmuletAllocationV2 and polish V2#4337
Conversation
tests pass! *yay*
8e1db7f to
cf7bdaf
Compare
This reverts commit 0af6c68.
... but its not pretty :/
meiersi-da
left a comment
There was a problem hiding this comment.
@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:
- double-checking our alignment on the API and its implementation
- 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.
token-standard/splice-api-token-utils-v2/daml/Splice/Api/Token/UtilsV2.daml
Outdated
Show resolved
Hide resolved
token-standard/splice-api-token-utils-v2/daml/Splice/Api/Token/UtilsV2.daml
Outdated
Show resolved
Hide resolved
| -- | ||
| -- 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. |
There was a problem hiding this comment.
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` |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
@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 | |||
There was a problem hiding this comment.
@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 | |||
There was a problem hiding this comment.
@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. |
There was a problem hiding this comment.
@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. |
There was a problem hiding this comment.
@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.
Pull Request Checklist
Cluster Testing
/cluster_teston this PR to request it, and ping someone with access to the DA-internal system to approve it./hdm_teston this PR to request it, and ping someone with access to the DA-internal system to approve it.PR Guidelines
Fixes #n, and mention issues worked on using#nMerge Guidelines