Let Upala IDs be generated deterministically from owner's address.

Related:

UIP-22. Let managers assign scores before Upala ID is created (decision to create non-deterministic upala IDs is here)

Number of delegates = number of liquidations? (score aggregation)

Pros.

That would allow group managers assign scores by ethereum address (if Upala id is not created yet).

That in turn would allow to ship bots-first version of Upala (no UX).

This setup would solve multiple liquiqudations problem for the SignedScoresPool and will also simplify contract logic when managers assign scores by address before UpalaID exists. Will

Better logic separation. Scores are assigned only to UpalaIDs. Delegates can only use the score.

Cons

• Cannot aggregate scores from multiple addresses within single ID (probably a good thing).

Notes (future)

Using keccak256 to make UpalaID look different from owner's address - should arise less confusion. E.g. in case if some-one would decide to change ID owner.

address(uint(keccak256(abi.encodePacked(newIdentityOwner, "boom!"))));

If user owns many address, that would arise a lot of confusion - may Upala IDs for single user (no way to unite different UpalaIDs)

Group managers would have to calculate Upala IDs (though simple, it does require some effort and understanding)