Skip to content

docs: wallet_account derivation-path fields for export policies #768

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
andrewkmin wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

docs: wallet_account derivation-path fields for export policies #768

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d93442f
docs: wallet_account derivation-path fields for export policies
andrewkmin Aug 10, 2026
51271ad
docs: error semantics and skew guidance for wallet_account path fields
andrewkmin Aug 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions features/policies/examples/access-control.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -179,3 +179,27 @@ This policy can be used to say, only passkeys are allowed to sign transactions a
"condition": "activity.action == 'EXPORT' && wallet_account.address == '<WALLET_ACCOUNT_ADDRESS>'"
}
```

#### Allow exporting only wallet accounts under a hardened derivation subtree

This policy allows exporting only wallet accounts whose derivation path is a fully-hardened,
4-segment path of the form `m/8797555'/x'/3'/y'` (a Spark-purpose subtree). Because single-quoted
policy literals cannot contain `'` (apostrophe), the path is matched structurally via
`wallet_account.path_indexes` and `wallet_account.path_hardened` rather than as a string. Note that
policies match the literal stored path; on ed25519, soft and hardened spellings derive the same key.

```json JSON
{
"policyName": "Allow exporting only accounts under m/8797555'/x'/3'/y'",
"effect": "EFFECT_ALLOW",
"consensus": "approvers.any(user, user.id == '<USER_ID>')",
"condition": "activity.kind == 'EXPORT_WALLET_ACCOUNT' && wallet_account.path_indexes.count() == 4 && wallet_account.path_indexes[0] == 8797555 && wallet_account.path_indexes[2] == 3 && wallet_account.path_hardened.all(h, h == true)"
}
```

The derivation-path fields are populated only for `EXPORT_WALLET_ACCOUNT` activities: on any other
activity, a condition referencing them produces an evaluation error (the policy's outcome is an
error, not a match against empty values). Prefer narrow allow policies like this one over combining
a broad allow with a path-based `EFFECT_DENY`: during rollout windows where some Turnkey components
do not yet know these fields, an erroring deny is skipped while a broad allow still matches (failing
open), whereas a narrow allow that errors fails closed.
30 changes: 30 additions & 0 deletions features/policies/language.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -116,6 +116,12 @@ The language is strongly typed which makes policies easy to author and maintain.
| | exported | bool | Boolean indicating whether or not this wallet has been exported |
| | label | string | The label of this wallet |
| **Wallet Account** | address | string | The wallet account address |
| | path | string | The account's BIP32 derivation path as stored, e.g. `m/44'/60'/0'/0/0` |
| | path_indexes | list\<int\> | The derivation path child indexes with the hardened bit stripped, e.g. `[44, 60, 0, 0, 0]` |
| | path_hardened | list\<bool\> | Positionally paired with `path_indexes`; true where the corresponding path segment is hardened |
| | wallet_id | string | The identifier of the wallet this account belongs to |
| | curve | string | The curve enum name, e.g. `CURVE_SECP256K1` |
| | address_format | string | The address format enum name, e.g. `ADDRESS_FORMAT_COMPRESSED` |
| **PrivateKey** | id | string | The identifier of the private key |
| | tags | list\<string\> | The collection of tags for the private key |
| | imported | bool | Boolean indicating whether or not this private key has been imported |
Expand Down Expand Up @@ -179,6 +185,30 @@ The language is strongly typed which makes policies easy to author and maintain.
Primitives section.{" "}
</Note>

<Note>
{" "}
Single-quoted policy string literals cannot contain `'` (apostrophe), so derivation paths like
`m/44'/60'/0'/0/0` cannot be matched as strings. This is why the Wallet Account derivation path
is exposed structurally via `path_indexes` and `path_hardened` in addition to `path`. The
`path`, `path_indexes`, `path_hardened`, `wallet_id`, `curve`, and `address_format` fields are
currently populated only for `EXPORT_WALLET_ACCOUNT` activities; other activities will follow.
On any other activity, a condition referencing these fields produces a `MissingField` evaluation
error — the policy's outcome is an error rather than a match against empty values (see
[Policy evaluation](#policy-evaluation) in the appendix), so an `EFFECT_ALLOW` policy that
references them does not grant access outside of exports.{" "}
</Note>

<Note>
{" "}
During a rollout window in which some Turnkey components have not yet been updated with these
fields (version skew), a condition referencing them can produce an evaluation error even on
`EXPORT_WALLET_ACCOUNT` activities. An erroring `EFFECT_ALLOW` policy fails closed (the export
is denied), but an erroring `EFFECT_DENY` policy is skipped — so pairing a broad allow (e.g.
"allow all exports") with a path-based deny can fail open during the skew window. Prefer narrow
allow policies that match only the derivation paths you intend to permit over broad-allow plus
path-deny combinations.{" "}
</Note>

#### Nested structs

| Struct | Field | Type | Description |
Expand Down