This is a proposal that needs further discussion before implementing.
It would be useful for the accounts and arguments of an InstructionNode to optionally contain a InstructionConstraintNode. These constraints would define rules for these accounts or arguments such that, if that constraint fails, the provided account or argument will fail to pass the instruction's checks.
Ideas for such constraints could be:
PdaConstraintNode: The account or argument (of type PublicKey) must follow the describe derivation.
PublicKeyConstraintNode: The account or argument (of type PublicKey) must be equal to the provided address.
PublicKeyListConstraintNode: The account or argument (of type PublicKey) must be included in the provided array of addresses.
ValueConstraintNode: The argument must be equal to the provided value.
HasOneConstraintNode: The account or argument must be present in the provided account and match the value of its attribute.
AndConstraintNode: All nested constraints must be valid.
OrConstraintNode: At least one nested constraint must be valid.
NotConstraintNode: The nested constraint must fail.
Side node: Currently, every account or argument in an InstructionNode has the potential to include a defaultValue which can either be a simple ValueNode or more contextual nodes such as ArgumentValueNode (to default to another argument), AccountValueNode (to default to another account), PdaValueNode (to default to a PDA derivation with seeds coming from other accounts or arguments), ConditionalValueNode (to provide simple if/else values), etc.
That defaultValue is mostly useful for renderers and documentation visitors as they allow the generated helper functions to require as little information as possible.
The constraint nodes cannot replace this defaultValue since constraints alone are not enough to decide which value an account or argument should default to. However, there could be some redundancy here to tackle such as the PdaConstraintNode and the PdaValueNode.
This is a proposal that needs further discussion before implementing.
It would be useful for the accounts and arguments of an
InstructionNodeto optionally contain aInstructionConstraintNode. These constraints would define rules for these accounts or arguments such that, if that constraint fails, the provided account or argument will fail to pass the instruction's checks.Ideas for such constraints could be:
PdaConstraintNode: The account or argument (of type PublicKey) must follow the describe derivation.PublicKeyConstraintNode: The account or argument (of type PublicKey) must be equal to the provided address.PublicKeyListConstraintNode: The account or argument (of type PublicKey) must be included in the provided array of addresses.ValueConstraintNode: The argument must be equal to the provided value.HasOneConstraintNode: The account or argument must be present in the provided account and match the value of its attribute.AndConstraintNode: All nested constraints must be valid.OrConstraintNode: At least one nested constraint must be valid.NotConstraintNode: The nested constraint must fail.Side node: Currently, every account or argument in an
InstructionNodehas the potential to include adefaultValuewhich can either be a simpleValueNodeor more contextual nodes such asArgumentValueNode(to default to another argument),AccountValueNode(to default to another account),PdaValueNode(to default to a PDA derivation with seeds coming from other accounts or arguments),ConditionalValueNode(to provide simple if/else values), etc.That
defaultValueis mostly useful for renderers and documentation visitors as they allow the generated helper functions to require as little information as possible.The constraint nodes cannot replace this
defaultValuesince constraints alone are not enough to decide which value an account or argument should default to. However, there could be some redundancy here to tackle such as thePdaConstraintNodeand thePdaValueNode.