Repository navigation
docs: authorization locks - #60
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… bound Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| vec![transfer(&wallet_address, &merchant, 1_500_000_000)], | ||
| Some(slot), | ||
| )?); | ||
| // Sign with the fee payer and the card authority, then send. |
There was a problem hiding this comment.
[NIT] Could this recipe include the complete signed-and-sent transaction for capture? Release and SignV2 must execute in one transaction, but the example stops after assembling instructions, so readers cannot run the central flow as shown.
edo-chan
left a comment
edo-chan
left a comment
There was a problem hiding this comment.
[NIT] Could you also refresh the SwigWallet::new signature and struct sketch in reference/rust/rust_wallet.mdx (lines 13-35)? They still show AuthorityManager and a required authority keypair, while the current SDK takes Box<dyn ClientRole> and an optional authority_keypair. The setup shown on this reference page will not compile against the current SDK.
|
|
||
| ### Grant the delegated role | ||
|
|
||
| The delegate can lock any asset it has a spending limit for, up to that limit, |
There was a problem hiding this comment.
Please describe the delegated cap as the remaining spending allowance after its existing active holds on the same asset, and the All/AllButManageAuthority cap as this asset account's unreserved, lockable balance. For native SOL, exclude the rent-exempt minimum. Apply the same wording in concepts-and-permissions; 'up to that limit' and 'the wallet’s balance' currently overstate what a new lock can reserve.
|
|
||
| A role with `All` or `AllButManageAuthority` also needs | ||
| `ManageAuthorizationLocks` to lock. It can then lock up to the wallet's balance, | ||
| still within its `max_duration_slots`. To let the root role lock, have it grant |
There was a problem hiding this comment.
Please state the root-role exception consistently here and in concepts-and-permissions: a non-root role cannot set or change its own max_duration_slots, while the root role can set or change its own bound. The protocol page already explains this exception.
| ### Release or prune a hold | ||
|
|
||
| ```rust | ||
| wallet.remove_authorization_lock(lock_id)?; |
There was a problem hiding this comment.
[NIT] Could the recipe show where lock_id comes from? The create helpers return only a transaction signature, so the release and capture snippets never establish the identifier. Once the SDK returns a transaction-correlated ID, carry it through this flow.
| longest a role can be pinned is the duration someone else granted it. | ||
|
|
||
| <Note> | ||
| An existing wallet's root role cannot lock until it grants itself |
There was a problem hiding this comment.
[NIT] Could this existing-wallet note also say locks require a V2 wallet and link the migration path? Both add and remove handlers call require_swig_v2, so granting the permission alone is insufficient for a legacy wallet.
Reflect anagrambuild/swig-wallet@dd2e69d: AddAuthorizationLockV1 (25) and RemoveAuthorizationLockV1 (26) now take the swig config and wallet address as accounts 0 and 1 so ProgramExec roles can authorize locks, and remove checks the wallet address PDA. - protocol page: account tables, discriminators, ProgramExec and ProgramExecSession lock roles - recipe: swig_interface new_with_program_exec builders, remove builders' new swig_wallet_address argument, InvalidSeedSwigAccount and ProgramExec binding errors - instruction builder reference: ProgramExecClientRole and wallet address notes Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Reflect anagrambuild/swig-wallet@9c1e0be (#226) and @760079c (#240): a lock holds other roles, All included, off the reserved funds, while the holder spends them and SignV2 captures its locks by the net outflow, oldest first. Fully captured locks stay stored at amount 0, inactive and prunable. Limits are charged on spend, and a limited holder's remaining locks must fit its remaining limits after each SignV2. - protocol page: enforcement rewritten, worked example, limits section, release/prune rules - recipe: capture by spending through SignV2 instead of release-then-spend - error 89 (AuthorizationLockViolated) and 85 descriptions - Rust reference, permissions and walkthrough wording Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Reflect anagrambuild/swig-wallet@30bcfc0 and acce97a: - RemoveAuthorityV1 removes a holder once all its locks are inactive (expired or captured to 0) and prunes those records in the same instruction, refunding their rent with the role's. One active lock still blocks removal, by any actor including the role itself. - Update/ReplaceAuthorityV1 on an inactive holder work as usual and keep its records; the active-lock exceptions are spelled out. - SignV2 needs no extra accounts for locks, never resizes the config or moves lamports for them, and captured-to-0 locks stay stored until pruned. Protocol page, recipe ("Remove the delegate" step), and the Rust remove_authority references. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
edo-chan
left a comment
edo-chan
left a comment
There was a problem hiding this comment.
The token-lock example needs the permission prerequisite described below.
|
|
||
| // Hold tokens in the wallet's associated token account for `mint`. | ||
| // SPL Token and Token-2022 mints are both supported. | ||
| wallet.add_token_authorization_lock(&mint, 600, slot + 400)?; |
There was a problem hiding this comment.
Please grant a token spending limit for mint before this call, and include the equivalent permission in the CLI example. Both grant examples currently give the delegate only a SOL limit, so the subsequent token lock fails with AuthorizationLockExceedsSpendLimit.
Authorization-lock documentation covers program rules, direct Rust/CLI flows, and hosted TypeScript, Python, and Rust preparation. The guides preserve explicit prerelease notices: the hosted API and SDK additions remain under review, and published Rust protocol crates 3.0.0 do not include the lock APIs.
Reconciles the guides with the current navigation and Rust reference APIs. Clarifies remaining lock capacity, native SOL rent, root-role duration changes, V2 migration, token permission prerequisites, and how to select an existing lock ID. CLI examples require a build containing merged wallet PR #240.
Dependencies still open: portal #1170, Protocol SDK #25, and Developer SDK #66/#79. This documentation merge does not deploy those changes or publish packages.
Validation: Mintlify build validation, internal links and anchors, and git diff --check passed. Independent source-backed documentation review passed. The final CLI source link was verified through GitHub. Hosted and on-chain calls were not executed in this pass.