createPolicy
Define a rule set and its agreement lifecycle.
Status
Proposed target SDK behavior for implementation. It is not an available policy engine or released expression grammar.
Business action#
Create a reusable allow or deny rule governing wallet actions. Creating a rule does not by itself make it effective for a wallet.
Proposed call#
createPolicy(
input: CreatePolicyInput,
options?: CallOptions,
): Promise<Operation<CreatePolicyResult>>
TypeScript uses requestId, name, effect, condition, optional agreementRequirement, notes, actor, and optional authorization. effect is a stable string union; undefined omits an optional field and cannot activate a rule.
async def create_policy(
input: CreatePolicyInput,
*,
options: CallOptions | None = None,
) -> Operation[CreatePolicyResult]: ...
Python uses request_id and agreement_requirement; effect is a string-valued enum and optional fields use UNSET. None is accepted only when a shared DTO explicitly permits it.
CreatePolicy(
ctx context.Context,
input *CreatePolicyInput,
) (*Operation[CreatePolicyResult], error)
Go uses RequestID, AgreementRequirement and a named string PolicyEffect with stable JSON values. Presence-aware fields distinguish omission from zero values; invalid input fails before submission.
Required input: requestId, name, allow/deny effect, explicit condition, optional owner-agreement requirement, notes and actor authorization. Exact rule grammar, precedence and limit accounting require a separate accepted implementation contract.
Result and effects#
Success returns policy ID, version, normalized scope and agreement requirement. updateWallet explicitly assigns the policy to a wallet.
Creation and enforcement are separate states:
createPolicystores version 1 of a reusable definition under a stable policy ID.- Until an explicit
updateWalletassignment succeeds, that definition affects no wallet. - Once assigned, the backend evaluates the assigned version for every protected action; a browser session cannot skip that evaluation.
For example, a team could define an allow rule for a bounded transfer action, a deny rule for an expressly blocked destination class, and an approval requirement for a higher-risk amount. These are semantic examples only, not runnable condition or quorum syntax. If the deny case matches, or the required independent approval is missing, no transaction is signed or submitted.
Same-ID/same-material replay converges; changed material conflicts. Unknown outcome is resolved through getOperation. Rejection creates no rule.
Agreement lifecycle#
A request within existing authority may complete immediately. When owner participation or multiple-party agreement is required, the SDK either uses the application handler and submits its response once or returns requiresAction for explicit continuation; it cannot do both. Each response binds the exact policy material, actor, request ID and expiry and is accumulated separately from immutable operation material. Denial, expiry or insufficient agreement ends explicitly; the SDK never exposes separate approve/reject CRUD as a required integration surface.
Creating a permissive or restrictive definition requires explicit owner/admin authority, but that authority still does not assign the rule. A logged-in session or claimed UI role cannot elevate itself into policy administration.
Acceptance#
- Positive: completed creation yields one readable rule whose intended allow and deny examples evaluate as specified once assigned.
- Negative: a policy name or accepted syntax alone does not attach it; empty/ambiguous conditions do not silently broaden authority; incomplete agreement cannot activate it.
See Policies, Approvals, updatePolicy, and updateWallet.