@settlemint/dalp-cli 3.1.33-main.43599357043 → 3.1.33-main.43609737112

package/dist/{openapi-surface-7r6m91cj.json → openapi-surface-fhfdkb1q.json}

@@ -18572,8 +18572,8 @@
       "method": "POST",
       "url": "/api/v2/users/me/custody-accounts/lifecycles",
       "summary": "Run a custody account lifecycle",
-      "description": "Takes one signed account-control proof and carries the whole lifecycle to its end: onboarding, Add account, revocation, or archival. The platform settles every step it can settle on its own. Where a step needs the holder's key, the response names the authorization to answer, the client answers it once through the transaction surface, and the platform carries the request the rest of the way without a second call here. By default the request is accepted with the 202 lifecycle handle and its status URL; send Prefer: wait=<seconds> to wait for the settled result instead.",
-      "help": "Takes one signed account-control proof and carries the whole lifecycle to its end: onboarding, Add account, revocation, or archival. The platform settles every step it can settle on its own. Where a step needs the holder's key, the response names the authorization to answer, the client answers it once through the transaction surface, and the platform carries the request the rest of the way without a second call here. By default the request is accepted with the 202 lifecycle handle and its status URL; send Prefer: wait=<seconds> to wait for the settled result instead.",
+      "description": "Takes one signed account-control proof and carries the whole lifecycle to its end: onboarding, Add account, revocation, or archival. The platform settles every step it can settle on its own. Where a step needs the holder's key, the response names the authorization to answer, the client answers it once through the transaction surface, and the platform carries the request the rest of the way without a second call here. By default the request is accepted with the 202 lifecycle handle and its status URL; send Prefer: wait=<seconds> to wait for the settled result instead. The request is wallet-verified, with one exception: a caller who has no wallet verification method yet (no transaction PIN, transaction code, recovery codes or authenticator) may onboard or add the participant's first signing key without sending one, when the participant holds no signing key that is not archived (a revoked key counts) and no key is being created or changed for it. The platform decides this itself, under a lock on the participant, once the control proof checks out, so of two concurrent first keys only one goes through without verification. Every revocation and archival needs the wallet verification, as does every other onboarding or add, a request that carries `walletVerification`, and any request once the caller has a verification method; without it the request is refused with `WALLET_VERIFICATION_REQUIRED`, or with `USER_MISSING_2FA` when the caller has no method to verify with. A session caller also sends the `X-Step-Up-Challenge` header, issued by `POST /api/v2/step-up-challenges` for this operation, target, and body; the challenge is single-use.",
+      "help": "Takes one signed account-control proof and carries the whole lifecycle to its end: onboarding, Add account, revocation, or archival. The platform settles every step it can settle on its own. Where a step needs the holder's key, the response names the authorization to answer, the client answers it once through the transaction surface, and the platform carries the request the rest of the way without a second call here. By default the request is accepted with the 202 lifecycle handle and its status URL; send Prefer: wait=<seconds> to wait for the settled result instead. The request is wallet-verified, with one exception: a caller who has no wallet verification method yet (no transaction PIN, transaction code, recovery codes or authenticator) may onboard or add the participant's first signing key without sending one, when the participant holds no signing key that is not archived (a revoked key counts) and no key is being created or changed for it. The platform decides this itself, under a lock on the participant, once the control proof checks out, so of two concurrent first keys only one goes through without verification. Every revocation and archival needs the wallet verification, as does every other onboarding or add, a request that carries `walletVerification`, and any request once the caller has a verification method; without it the request is refused with `WALLET_VERIFICATION_REQUIRED`, or with `USER_MISSING_2FA` when the caller has no method to verify with. A session caller also sends the `X-Step-Up-Challenge` header, issued by `POST /api/v2/step-up-challenges` for this operation, target, and body; the challenge is single-use.",
       "tags": [
         "Users"
       ],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@settlemint/dalp-cli",
-  "version": "3.1.33-main.43599357043",
+  "version": "3.1.33-main.43609737112",
   "private": false,
   "description": "CLI for the Digital Asset Lifecycle Platform — manage tokens, identities, compliance, and more from the command line.",
   "homepage": "https://settlemint.com",
@@ -50,14 +50,14 @@
   },
   "dependencies": {
     "@modelcontextprotocol/server": "2.4.0",
-    "@settlemint/dalp-sdk": "3.1.33-main.43599357043",
+    "@settlemint/dalp-sdk": "3.1.33-main.43609737112",
     "incur": "0.7.1",
     "zod": "4.6.7"
   },
   "devDependencies": {
     "@arethetypeswrong/cli": "0.18.5",
-    "@testkit/effect-bun-test": "3.1.33-main.43599357043",
-    "@tools/typescript-config": "3.1.33-main.43599357043",
+    "@testkit/effect-bun-test": "3.1.33-main.43609737112",
+    "@tools/typescript-config": "3.1.33-main.43609737112",
     "@types/bun": "1.4.4",
     "publint": "0.3.25"
   },

package/src/generated/openapi-surface.json

@@ -18572,8 +18572,8 @@
       "method": "POST",
       "url": "/api/v2/users/me/custody-accounts/lifecycles",
       "summary": "Run a custody account lifecycle",
-      "description": "Takes one signed account-control proof and carries the whole lifecycle to its end: onboarding, Add account, revocation, or archival. The platform settles every step it can settle on its own. Where a step needs the holder's key, the response names the authorization to answer, the client answers it once through the transaction surface, and the platform carries the request the rest of the way without a second call here. By default the request is accepted with the 202 lifecycle handle and its status URL; send Prefer: wait=<seconds> to wait for the settled result instead.",
-      "help": "Takes one signed account-control proof and carries the whole lifecycle to its end: onboarding, Add account, revocation, or archival. The platform settles every step it can settle on its own. Where a step needs the holder's key, the response names the authorization to answer, the client answers it once through the transaction surface, and the platform carries the request the rest of the way without a second call here. By default the request is accepted with the 202 lifecycle handle and its status URL; send Prefer: wait=<seconds> to wait for the settled result instead.",
+      "description": "Takes one signed account-control proof and carries the whole lifecycle to its end: onboarding, Add account, revocation, or archival. The platform settles every step it can settle on its own. Where a step needs the holder's key, the response names the authorization to answer, the client answers it once through the transaction surface, and the platform carries the request the rest of the way without a second call here. By default the request is accepted with the 202 lifecycle handle and its status URL; send Prefer: wait=<seconds> to wait for the settled result instead. The request is wallet-verified, with one exception: a caller who has no wallet verification method yet (no transaction PIN, transaction code, recovery codes or authenticator) may onboard or add the participant's first signing key without sending one, when the participant holds no signing key that is not archived (a revoked key counts) and no key is being created or changed for it. The platform decides this itself, under a lock on the participant, once the control proof checks out, so of two concurrent first keys only one goes through without verification. Every revocation and archival needs the wallet verification, as does every other onboarding or add, a request that carries `walletVerification`, and any request once the caller has a verification method; without it the request is refused with `WALLET_VERIFICATION_REQUIRED`, or with `USER_MISSING_2FA` when the caller has no method to verify with. A session caller also sends the `X-Step-Up-Challenge` header, issued by `POST /api/v2/step-up-challenges` for this operation, target, and body; the challenge is single-use.",
+      "help": "Takes one signed account-control proof and carries the whole lifecycle to its end: onboarding, Add account, revocation, or archival. The platform settles every step it can settle on its own. Where a step needs the holder's key, the response names the authorization to answer, the client answers it once through the transaction surface, and the platform carries the request the rest of the way without a second call here. By default the request is accepted with the 202 lifecycle handle and its status URL; send Prefer: wait=<seconds> to wait for the settled result instead. The request is wallet-verified, with one exception: a caller who has no wallet verification method yet (no transaction PIN, transaction code, recovery codes or authenticator) may onboard or add the participant's first signing key without sending one, when the participant holds no signing key that is not archived (a revoked key counts) and no key is being created or changed for it. The platform decides this itself, under a lock on the participant, once the control proof checks out, so of two concurrent first keys only one goes through without verification. Every revocation and archival needs the wallet verification, as does every other onboarding or add, a request that carries `walletVerification`, and any request once the caller has a verification method; without it the request is refused with `WALLET_VERIFICATION_REQUIRED`, or with `USER_MISSING_2FA` when the caller has no method to verify with. A session caller also sends the `X-Step-Up-Challenge` header, issued by `POST /api/v2/step-up-challenges` for this operation, target, and body; the challenge is single-use.",
       "tags": [
         "Users"
       ],