native splitter #102
native splitter #102
Conversation
bekauz
force-pushed
the
benskey/native-splitter
branch
from
043af79
to
21b80d9
Compare
There was a problem hiding this comment.
Regarding the precision of the % we want, right now you only handle rounded % (50%, 51%, 25%), but there might be cases where we want a fractioned % (33.33%, 12.5%), in that case we better move to a BPS system.
I think we should stick with 100%, and not complicate it further.
| } | ||
|
|
||
| impl NativeDenomSplit { | ||
| pub fn validate(self) -> Result<NativeDenomSplit, StdError> { |
There was a problem hiding this comment.
Dont forget to confirm that the denoms are the same as well.
There was a problem hiding this comment.
So in here it handles multiple denoms with their individual splits:
pub struct NativeDenomSplit {
/// denom to be distributed
pub denom: String,
/// denom receivers and their respective shares
pub receivers: Vec<SplitReceiver>,
}Though now that I think of it, a good validation is to make sure that there are no two NativeDenomSplits with the same denom. Will add.
| pub enum ExecuteMsg {} | ||
|
|
||
| #[cw_serde] | ||
| pub struct SplitConfigMap { |
There was a problem hiding this comment.
Map that maps denoms to vec of receivers with their shares for that denom. Added a comment.
There was a problem hiding this comment.
Are you using that? Seems like theres a state with same name?
…ated entries with same denom
base implementation for #91
to be reviewed after #98 is merged
at the moment the split configuration expects all receiver shares to add up to 100 (indicating percentages). feels like this can be simplified to take in arbitrary amounts that would get converted to fractions relative to inputs. e.g.: given three receivers with shares of
(20, 30, 10)that add up to 60, we would be looking at a split of (20/60, 30/60, 10/60). wasn't sure if it's the right move yet so keeping it open for future.