Repository navigation
feat: authorization lock methods - #66
Merged
Merged
Conversation
austbot
marked this pull request as ready for review
November 2, 2026 17:10
Add authorization-lock preparation and read methods to both SDKs, targeting
the new dev portal routes:
- POST /transaction/wallet/authorization-lock/add
- POST /transaction/wallet/authorization-lock/remove
- GET /transaction/wallet/{swig_address}/authorization-locks
TypeScript: wallet.addAuthorizationLock, wallet.removeAuthorizationLock,
wallet.getAuthorizationLocks. Python: wallet.add_authorization_lock,
wallet.remove_authorization_lock, wallet.get_authorization_locks. Both
recognize the add-authorization-lock and remove-authorization-lock prepared
transaction kinds.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lock requesters may now be Ed25519 (direct or session key), Secp256k1, or Secp256r1 in both SDKs; ProgramExec and ParticipantSet are rejected before any request is sent. The Swig signing helpers previously located the authority payload only in SignV2. They now also recognize AddAuthorizationLockV1 (discriminator 25, 88-byte args) and RemoveAuthorizationLockV1 (26, 16-byte args), so secp256k1 signatures and prefixes, and secp256r1 passkey prefixes, are written into lock instructions the same way. Raw secp256r1 signatures already worked through the precompile path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Follow swig-dev-portal#1170 (104b34dd): - Allow ParticipantSet requesters (optional roleId) on add/remove lock in both SDKs; keep rejecting programExecProof. The response's approval plan compiles through the existing compileParticipantSetApprovals flow. - TypeScript compileParticipantSetApprovals now sends the lock prepared kinds instead of dropping them, so the compiled transaction keeps its kind (Python already did). - Update lock signing tests to the new account order (wallet address at index 1) and the server-placed EIP-191 prefix, and verify SDK-produced secp256k1 signatures recover the requester under the program's keccak256(prefix || hex(sha256(payload))) algorithm, including a rent claimer that is also the fee payer. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Follow swig-wallet authlock-v3 9c1e0be. Other roles, All and the owner included, spend only the balance minus locks they don't hold; the holder spends its locked funds and each spend captures its lock amount. Locking charges no spend limit; spending does. Fully captured locks stay stored with amount 0, inactive, prunable, and returned only with include_expired. Update READMEs, CHANGELOG, PARITY.md, ENGINEERING_CONTRACT.md, JSDoc and docstrings accordingly. The lock normalizers already accept a zero amount; add tests that a zero-amount inactive lock normalizes in both SDKs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
edo-chan
force-pushed
the
feat/authorization-locks
branch
from
November 3, 2026 20:11
03fdb77 to
b956b7e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds authorization-lock preparation and inspection to the TypeScript and Python SDKs, rebased onto current main. Both clients expose add, remove, and list methods; captured locks remain visible as amount zero/inactive when requested.
The signing helpers recognize AddAuthorizationLockV1 (25; 88-byte args) and RemoveAuthorizationLockV1 (26; 16-byte args), preserving k1 prefixes, r1 precompile signatures and ParticipantSet approval compilation. Request validation enforces expiry exclusivity, integer ranges and supported authorities. Response validation rejects malformed uint32 IDs and uint64 amounts/slots.
Prepared kind numbers are now 10/11 to match rebased swig-dev-portal#1170; main's Yield kinds 7/8/9 are not misidentified as locks. Protocol compatibility was checked against swig-wallet#226 at 4628591963a1f6d9196bae67b25fba6c4a9fb0ab. Upstream-removed documentation stays removed; the package README updates are preserved.
Validation on b956b7e:
Deployment dependency remains swig-dev-portal#1170 routes plus the authorization-lock program from swig-wallet#226. This update does not merge or deploy either dependency.