Creators shares values

[giorgionocera]

In the nft module, each Metadata can be linked to a list of Creators.
These objects are made up of

  string address = 1;
  bool verified = 2;
  uint32 share = 3;

Here, the share attribute is expressed

go-bitsong/proto/bitsong/nft/v1beta1/nft.proto

Line 59 in afcba32

// In percentages, NOT basis points ;) Watch out!

So I expect that their values should sum to 100. Instead, by looking at the implementation of the ProcessRoyalties method

go-bitsong/x/marketplace/keeper/royalties.go

Lines 8 to 37 in afcba32

	func (k Keeper) ProcessRoyalties(ctx sdk.Context, metadata nfttypes.Metadata, authority sdk.AccAddress, denom string, amount uint64) error {
	if metadata.SellerFeeBasisPoints > 100 {
	return nfttypes.ErrInvalidSellerFeeBasisPoints
	}
	totalRoyalties := amount * uint64(metadata.SellerFeeBasisPoints) / 100
	totalShare := uint32(0)
	for _, creator := range metadata.Creators {
	totalShare += creator.Share
	}
	if totalShare == 0 {
	return nil
	}
	for _, creator := range metadata.Creators {
	amount = totalRoyalties * uint64(creator.Share) / uint64(totalShare)
	if amount == 0 {
	continue
	}
	creatorAddr, err := sdk.AccAddressFromBech32(creator.Address)
	if err != nil {
	return err
	}
	err = k.bankKeeper.SendCoins(ctx, authority, creatorAddr, sdk.Coins{sdk.NewInt64Coin(denom, int64(amount))})
	if err != nil {
	return err
	}
	}
	return nil
	}

It seems that those values could also sum to any number, and the royalties would be redistributed in this sense.
Since this approach is used by many (like osmosis), it is common when a large set of users can split a value in a very dynamic way.

In this case, since this partition should be very static, IMHO I suggest moving it to values in the range [0;10000] that must sum to 10000. In this way it is also simpler to see which percentage is assigned to each creator, since, from the comment, these values should be percentages.