#baby $BABY One detail I found interesting while reading Babylon's checkpointing documentation is how it works within Bitcoin's OP_RETURN limits.
Bitcoin allows up to 80 bytes of data in an OP_RETURN output. A Babylon checkpoint includes multiple pieces of information—such as the epoch number, checkpoint hash, validator bitmap, and an aggregated BLS signature. Together, that data is larger than what a single OP_RETURN output can hold.
Instead of trying to bypass Bitcoin's rules, Babylon publishes the checkpoint across two Bitcoin transactions, each containing its own OP_RETURN output. This isn't presented as a bug or a temporary workaround—it's simply the design choice that fits Bitcoin's current protocol constraints.
I think it's a good example of building around Bitcoin's existing rules rather than expecting the base layer to change.
@BabylonLabs_io $BABY #baby
Bitcoin allows up to 80 bytes of data in an OP_RETURN output. A Babylon checkpoint includes multiple pieces of information—such as the epoch number, checkpoint hash, validator bitmap, and an aggregated BLS signature. Together, that data is larger than what a single OP_RETURN output can hold.
Instead of trying to bypass Bitcoin's rules, Babylon publishes the checkpoint across two Bitcoin transactions, each containing its own OP_RETURN output. This isn't presented as a bug or a temporary workaround—it's simply the design choice that fits Bitcoin's current protocol constraints.
I think it's a good example of building around Bitcoin's existing rules rather than expecting the base layer to change.
@BabylonLabs_io $BABY #baby