DO NOT MERGE

[jrwbabylonlab]

No description provided.

[gusin13]

I thought about this again, I kind of like your original idea (option2) i.e keeping another field in db. This saves us from overcomplicating the original indexer states.

In short why don't we have another field which is basically a sub_state

type BTCDelegationDetails struct {
// ... existing fields ...


State types.DelegationState bson:"state"
SubState string bson:"sub_state,omitempty"


// ... existing fields ...
}

The sub_state would be limited to three values: (this is in sync with our btc script paths)

• timelock
• unbonding
• slashing

This field would only be present when the parent state is:

• unbonding
• withdrawable
• withdrawn

we can name this field sth else as well like btc_script_path etc
wdyt?

[jrwbabylonlab]

I thought about this again, I kind of like your original idea (option2) i.e keeping another field in db. This saves us from overcomplicating the original indexer states.

In short why don't we have another field which is basically a sub_state

type BTCDelegationDetails struct {
// ... existing fields ...


State types.DelegationState bson:"state"
SubState string bson:"sub_state,omitempty"


// ... existing fields ...
}

The sub_state would be limited to three values: (this is in sync with our btc script paths)

• timelock
• unbonding
• slashing

This field would only be present when the parent state is:

• unbonding
• withdrawable
• withdrawn

we can name this field sth else as well like btc_script_path etc wdyt?

Sounds good to me. my only question is with this sub-state approach, do you need to delete this field value when state changed to the next one?