Related

Cross-chain explosion window

UIP-16. Multiple approved addresses for a single ID

UIP-22. Let managers assign scores before Upala ID is created

Decision

Problem of aggregation is the same as

Thinking

If single person collected multiple scores for different address, they can always assign those address as delegates to different Upala IDs and liquidate them all.

A bigger question. How can user aggregate scores for multiple Upala IDs they own? Would they liquidate those one by one? How would groups sumup user scores?

Seems like there’s no difference between multiple UpalaIDs and single Upala ID with delegates with scores.

Actually we’ll face aggregating problem when dealing with cross-chain Cross-chain explosion window

Why does this matter at all?

In general, this is ok. With current setup, having multiple delegates only serves for user convenience. There’s no sense in increasing user score if they collected multiple delegates under the same ID. All those can be split again to multiple IDs and liquidated separately.

So this problem sounds more of:

We can add more sense to delegates.

UPDT 22.06.2023. No we could better stick to the logic where delegates just control the ID.

Solutions

Add timestamp to delegation

We can stretch delegation drop in time via commit-reveal scheme. So that group manages will have time to adjust their scores, if changes happen in user’s delegates. This mostly relates to summing up scores. Let this solution mature…