Skip to main content

Design Principles

The constraints API was built on the following design principles.

Expressivity​

The API should be maximally expressive to cover multiple use cases. In essence, a constraint submission is an array of { transaction, index } entries. The transaction field is required, while the index is not. This allows for the following patterns:

  • Single transactions with no ordering preference: array of a single transaction
  • Bundles at the top of the block: array of multiple transactions with indexes starting at 0
  • Bundles at the rest of the block, only preference over relative ordering: array of multiple transactions without indexes

We believe these constraint primitives should be able to cover most commitment types: ToB / RoB auctions, inclusion preconfirmations, execution preconfirmations etc.

Simplicity​

The { transaction, index } constraint schema is very simple.

Verifiability​

Proposers should be able to verify the constraints on any builder bids without needing to know the contents of the payload. This schema allows for the generation of proofs for any of the constraint patterns. See inclusion proofs for more information.