You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 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
InstructionNode
has the potential to include adefaultValue
which can either be a simpleValueNode
or 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
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 thePdaConstraintNode
and thePdaValueNode
.The text was updated successfully, but these errors were encountered: