Token Standard V2: adding a party to an allocation's executor set after the funds are locked

Hi,
Been working in the auctions layer of CAP / Concordia (Dev Fund #184) these past weeks. I’m building a sealed-bid first-price auction that settles over the Token Standard V2, with the lot and the payment instruments administered by different registries.
In an auction we want the seller to lock the lot before the winner is known. As I read it Token Standard V2 has an answer for legs discovered at settlement time: lock with transferLegSides = [] and nextIterationFunding = Some {...}, and fill the receiver in later through extraTransferLegSides on Allocation_Settle. But those are supplied by the executors, so whoever is in the executor set decides where the lot ends up. The executor set is fixed when the funds are locked, which is before the winner exists. To stop the operator and the seller from sending the lot to the wrong party, the winner should be in the executor set, but it cannot be named yet.
Rather than make the seller allocate against every bidder, I’m thinking about a first allocation under executors [operator, seller](where the operator must be trusted to run the auction) and then on resolution the lot is re-allocated under [winner, operator, seller]. That seems a safe step, provided the re-allocation and an Execution contract signed by all three are both created in the resolve transaction, so there is no moment where an outcome exists and the executor set doesn’t match it.
I am not sure this is what V2 intended, though. Allocation has three choices and none of them changes SettlementInfo, so the only way to add a party to the executor set is to cancel and allocate again through AllocationFactory_Allocate. That drags a registry handle into the auction resolution.
I would like to ask whether there’s a good way to express this: an allocation whose funds have to be locked before the parties who will authorise its settlement are known. Here that party is the winner. Has anyone working on auctions run into this and addressed it a different way?
Two constraints, in case they change the answer. The lot should to be locked before the auction resolves. And settlement has to be a separate transaction from resolution, because a format built on this may need to gate settlement on conditions the resolve can’t see.
Is there a shape on the interfaces as they stand that I’ve missed?
One flag if you go looking at the repo: I’m reworking the interfaces, don’t take what’s published as the shape it’ll land in.

Good question. The default option would be to allocate with executors = [operator] and trust them to run both the auction and the auction’s settlement. Why is that not an option in your case?

Thanks @Simon_Meier .

From my reading of Token Standard V2, cross-registry settlement can only be guaranteed to be atomic by the executor set. So with executors = [operator], the operator isn’t just trusted for liveness and honest resolution. It is trusted for custody as well. It can settle any bidder’s allocation, or the lot allocation, even before running the auction. The lot can even redirect it for any party it wants, because the lot allocation cannot name the receiver before running the auction. With the seller and winner in the executor set, neither leg can be settled alone: the winner pays only in the transaction that delivers the lot, and the seller delivers only against a payment.

Yes, it is true that the operator needs to be trusted with properly setting allocations. In TradFi that trust is standard.

For decentralized exachanges, what I’d recommend is to decentralize the operator party and have Daml models that govern what the operator party can do, which is the same pattern we use for making the dso party of the Global Synchronizer and Canton coin trustworthy. See splice/docs/src/background/architecture.rst at 9082ef2a0ad143a6409e60e76ce47c350e6bb93c · canton-network/splice · GitHub

Simon_Meier:

Yes, it is true that the operator needs to be trusted with properly setting allocations. In TradFi that trust is standard.

For decentralized exachanges, what I’d recommend is to decentralize the operator party and have Daml models that govern what the operator party can do, which is the same pattern we use for making the dso party of the Global Synchronizer and Canton coin trustworthy. See splice/docs/src/background/architecture.rst at 9082ef2a0ad143a6409e60e76ce47c350e6bb93c · canton-network/splice · GitHub

I had no particular use case for the auctions in mind. The idea is to understand what the library can express, and for academic research purposes.

I did have the decentralized party in mind. However, for some use cases, it might be hard to find entities suitable to host it, since every host would see the sealed bids.

Agreed with Simon.

We had a potentially-related thought that maybe - in such situations - it’s possible the hosts of the executor party need not see the bids at all.

But I may be missing something and that sounds like its own thread anyway.

I’m following Simon’s advice and avoid possibly unnecessary complexity.

The only way I could find to hide the bids from the executor party was to lock the same amount for all bidders, which caps the highest bid.

Thank you for the inputs ! @Simon_Meier @Colin