Covenant emulator

Description

The covenant emulator is responsible for fetching pending BTC delegations, doing validation and ensuring several invariants, sending these delegations to the covenant-signer for signing, and then publishing these signatures to the Babylon node.

Invariants

For reference, here is an example.

The first validation is that all delegations that were already signed (delegation.CovenantSigs.Pk == ce.Pk) are skipped, since they have already been signed. Then the delegations are batched into groups of SigsBatchSizes. Each delegation in the batch again goes through a validation process:

• The sigs cannot be fulfilled (this is the same as an earlier check of the CovenantSigs and a check on the number of sigs).

• The unbonding time is sane; the unbonding time is at least greater than or equal to the minimum unbonding time.

• The staking time is within the minimum and maximum values.

• The staking amount is within the minimum and maximum values.

• The btcstaking functions are used to verify that the BTC delegation slashing and funding TXs match.

• The unbonding fee exactly matches the difference between the staking and unbonding TX outputs.

Test coverage

Cases covered

• E2E tests for the life cycle of a BTC delegation from pending, to the covenant signatures being added and becoming verified, and the covenant signatures being added to Babylon

• E2E tests for the life cycle of a BTC delegation from pending, to the covenant signatures being added and becoming verified, and the covenant signatures being added to Babylon using remote signers

Cases not covered

• The individual validations are not tested for all the invariants specified.

Attack surface

The attack surface would include anything that can stop the covenant messages from being sent, such as the BTC delegation batches being set too large. Any invariant that causes valid messages to be discarded is also a valid attack surface.