@xkova/sdk 0.1.0-alpha.1 → 0.1.0-alpha.10

package/README.md

@@ -6,7 +6,7 @@ holders, wallets, payments, tokenization, and other customer resources.
 ## Install
 
 ```bash
-npm install @xkova/sdk@0.1.0-alpha.1
+npm install @xkova/sdk@alpha
 ```
 
 Requires Node.js 22 or newer. Keep this package and your API keys on the server.
@@ -93,6 +93,83 @@ one live successor; either key can be revoked immediately.
 
 ## Typed resources
 
+### Customer workforce applications
+
+Use `@xkova/sdk/workforce-bff` on a confidential server for an institution's
+staff application. It is separate from member login and Console operator
+sessions. The Console administrator first registers an exact issuer, audience,
+JWKS endpoint, application origins/callbacks and dedicated workspace API
+principal. They explicitly admit each immutable provider subject to an existing
+staff membership with narrowed roles and assigned resources. Email and provider
+groups never grant authority. A transport key cannot admit its own users.
+
+```ts
+import { XKOVAWorkforceBffClient } from '@xkova/sdk/workforce-bff';
+
+const workforce = new XKOVAWorkforceBffClient({
+  baseUrl: 'https://sandbox-api.xkova.com',
+  apiKey: process.env.XKOVA_WORKFORCE_API_KEY!,
+  workforceKey: process.env.XKOVA_WORKFORCE_KEY!,
+});
+```
+
+Use separate encrypted durable transaction/session stores implementing
+`XKOVAWorkforceStore`. Each write must commit independently of a later callback
+error. Serialize each reference across replicas, and make `replace` fail when
+the record is absent. The included PostgreSQL adapter demonstrates this contract.
+Use a distinct namespace from member sessions. Keep session material, provider
+proofs, PKCE verifiers and refresh attempts on the server.
+
+`beginAuthorization` returns the registered provider endpoint, audience, nonce,
+PKCE challenge and policy. Use a short-lived HttpOnly flow cookie for its state.
+Your BFF exchanges the real provider code and verifies its signature, issuer,
+audience, nonce and PKCE through `completeAuthorizationCallback`. XKOVA performs
+its own registered-provider verification before issuing the workforce session.
+An uncertain provider exchange cannot redeem the code again. A staged proof can
+recover the same API exchange attempt. A provider token's actual expiry bounds
+the session; refreshing XKOVA credentials does not refresh upstream identity.
+
+Read only `projectXKOVAWorkforceSession` into browser UI. Resolve resource access
+per request with `resolveResources({ reference, sessionStore, browserOrigin })`.
+The browser's Origin and session-bound CSRF proof must be checked before writes.
+The BFF pins its registered origin, workforce application and resolved human
+session. Roles/scopes/resources are intersected by the API, never combined with
+the transport principal's authority. A member credential cannot supply workforce
+authority, and workforce sessions cannot enter Console operator routes.
+
+For `human_authorization_required`, preserve the exact request, body, origin and
+idempotency key in a private review record. Use `inspectAction` and
+`beginActionProof` for its exact `authorization_token`. Show the returned review
+before starting real fresh provider authentication with the returned nonce and
+qualified assurance policy. Validate the provider callback's own state, PKCE,
+issuer, audience, nonce and current subject; require fresh authentication rather
+than accepting a cached login. Submit the real token with `completeActionProof`.
+Keep its short-lived grant server-side and pass it as `actionGrant` to
+`resolveResources` for only the unchanged frozen request. A grant never approves
+another request or replaces independent Safe signatures/quorum. These methods
+do not automatically retry an action or an uncertain proof completion.
+
+`logoutSession` durably blocks the local session before retiring it at XKOVA.
+Retry only that same logout if the network result is uncertain. It does not
+promise a global logout at the external provider. No request may fall back to a
+machine principal after workforce authentication fails.
+
+The resolved `wallets` resource supports `list`, `provision`, `register` and
+`signingBootstrap`. Provisioning and signing need the exact one-use human grant.
+Register only after signing the API's returned enrollment typed data. Signing
+bootstrap requires the existing proposal ID, its frozen Safe digest and nonce.
+Use `@xkova/browser/wallet` for the isolated browser ceremony, with a fresh
+purpose-bound admission and the expected wallet address. Keep the BFF key,
+provider proofs and workforce session credentials on the server. Provider
+admission does not replace wallet possession, current signer eligibility,
+independent-person quorum or confirmed chain settlement.
+
+Workforce session staff IDs and assigned treasury/token IDs use the API's
+canonical 22-character base62 bodies (`stf_`, `vlt_`, `ctk_`). Preserve these
+opaque values exactly. Server SDK alpha.9 fixes alpha.8's incorrect rejection
+of these API responses. The separate enrollment typed-data UUID strings must
+also remain unchanged; they are not the session's public resource IDs.
+
 Call resource methods with typed inputs:
 
 ```ts
@@ -113,6 +190,48 @@ const paymentRequests = await xkova.paymentRequests.list({ limit: 25 });
 
 Writes accept an optional caller-provided `idempotencyKey`. Reuse the same key when retrying the same logical request. If omitted, the SDK generates a new key for that individual call.
 
+Optional mutation queries follow the existing mutation options. For contact
+search, pass the returned cursor to fetch another page; each page is a distinct
+request, so use a new idempotency key or leave the options undefined:
+
+```ts
+const matches = await xkova.contacts.search(
+  { account_holder_id: holderId, email: contactEmail },
+  undefined,
+  { cursor: nextCursor, limit: 25 },
+);
+```
+
+Signer removal accepts its explicit acknowledgement as the fourth argument:
+
+```ts
+await xkova.treasury.deleteSigner(
+  vaultId,
+  signerStaffId,
+  { idempotencyKey: crypto.randomUUID() },
+  { acknowledged_unsafe: true },
+);
+```
+
+Set that flag only after reviewing the reduced lost-key safety buffer. Omission
+keeps the API's normal safety check; the SDK never selects acknowledgement.
+The API's minimum threshold, human authorization, current signer authority and
+other controls still apply.
+
+Optional bodies for webhook secret rotation, token pause/unpause and access
+registry disable follow the existing mutation options as a third argument:
+
+```ts
+await xkova.webhooks.rotateSecret(
+  endpointId,
+  { idempotencyKey: crypto.randomUUID() },
+  { overlap_sec: 120 },
+);
+```
+
+Omitting that body keeps the API's default behavior. If a token operation's
+body includes `idempotencyKey`, keep it equal to the mutation option's key.
+
 Account-holder `self` methods require a member session and its application's
 publishable key. Load both from your BFF's session store. These methods act on
 the signed-in account holder; browser input cannot select a different person:
@@ -124,6 +243,10 @@ const balance = await xkova.accountHolders.selfBalance({
 });
 ```
 
+`selfBalance` can return a partial answer. A chain not known right now has no
+entries in `balances` and a null `through_block` in `data_freshness`, so check
+that before treating a missing token as zero or adding balances together.
+
 ## Register a Hosted Auth application
 
 Hosted Auth provides an optional XKOVA-hosted sign-in flow. Register an
@@ -197,26 +320,17 @@ For your own OIDC provider, use `beginAuthorization` and
 code unless your integration explicitly assigns that exchange to XKOVA. Both
 sign-in paths use the same XKOVA session and store contracts.
 
-### Sandbox demo sign-in
-
-For a sandbox application explicitly enabled for demo sign-in, call
-`completeSandboxDemoAuthorization({ state: start.state, transactionStore })`
-after `beginHostedAuthorization`. The SDK obtains the capability and exact
-callback from the server-held transaction, validates the returned callback and
-expiry, and returns `{ callbackUrl, expiresAt }`. Complete that callback through
-`completeHostedAuthorization` with the original browser flow cookie. The API
-reserves a demo account for the session. This operation is not
-available to ordinary tenant applications or production workspaces, and it
-accepts no member, email, wallet, or callback selector.
-
-Keep the same pending reservation and transaction after an ambiguous admission
-failure. Repeating the method uses the same idempotency key and recovers the
-same demo account reservation. The method never retries automatically.
-`isDefinitiveXKOVASandboxDemoAdmissionFailure(error)` identifies confirmed
-rejection before an account was reserved; network, malformed-response, and
-unknown server failures can leave the reservation outcome uncertain.
-API errors retain their status, correlation ID, and Retry-After. Both admission
-and session requests reject HTTP redirects.
+### Local development
+
+The SDK accepts HTTP API URLs, browser origins, callbacks, and storage URLs on
+`localhost` and `127.0.0.1`. Remote hosts require HTTPS. Register each origin
+and callback with its exact scheme, host, port, and path. These two local hosts
+are distinct origins; cookies and browser storage are not shared between them.
+
+For local passkeys, serve the authentication page on `localhost` and use
+`localhost` as its relying-party ID. An IP address cannot be a passkey
+relying-party ID. Keep API keys and member sessions in your BFF, including
+during local development.
 
 ### Stores and callback recovery
 
@@ -225,6 +339,26 @@ proofs, and manages session refresh and logout. Implement its session,
 authorization-transaction, and direct proof-exchange store contracts in your
 own database. It does not include a web framework or database adapter.
 
+`runExclusive` is an exclusivity boundary, not an all-or-nothing SQL
+transaction. Every awaited `put`, `replace` and `delete` must commit before
+returning, and remain committed if later callback work throws. Wrapping the
+whole callback in a rollback transaction can erase a staged proof after its
+one-time provider code was consumed. The same rule protects refresh-attempt
+checkpoints. Reconcile an uncertain write acknowledgement using the exact
+record and attempt identity, rather than starting a new operation.
+
+The package includes [a PostgreSQL checkpoint-store example](examples/postgres-checkpoint-store.mjs)
+and its [application-owned table definition](examples/postgres-checkpoints.sql).
+Install `pg` in your backend and apply the table definition through your own
+migration process. Instantiate separate stores with namespaces such as
+`authorization`, `sessions` and `exchange`, one shared pool and an existing
+32-byte application encryption key. The example uses session advisory locks
+across replicas, independent autocommit checkpoints, authenticated encryption
+bound to namespace/reference, exact replacement without upsert, and connection
+discard when lock release is uncertain. Do not use a transaction-pooling proxy
+for session locks. Own key rotation, pool deadlines and expired-record cleanup
+in your application; do not log records or encryption material.
+
 Authorization, Account Center, and action transactions expire within ten
 minutes of starting the request, or at the server's expiry if sooner. Late,
 expired, or excessively long-lived responses are rejected. Keep your BFF's
@@ -255,8 +389,60 @@ To exchange a proof without a browser callback, call `establishSession` with an
 `exchangeId`. Persist that ID before the first attempt and reuse it on retries.
 The store serializes attempts and preserves the exchange and session references.
 
+### Enroll an external identity-provider member
+
+For a registered OIDC connection, the confidential backend can call
+`memberAuth.enrollExternalMember({ externalSub, applicationConfigVersion,
+idempotencyKey })`. Use the exact opaque subject from a fully verified provider
+proof, the final read-back application configuration version, and one persisted
+operation key. Never link by email. The API derives issuer namespace, tenant,
+workspace and application from the registered connection and its bound
+`member_auth` API principal. The header selector and body selector must match.
+An existing issuer/subject membership is returned without replacing its identity,
+status or wallet bindings. A held or closed member remains held or closed.
+
+Enrollment creates or finds a membership, not an authenticated session or wallet.
+The normal nonce-bound provider-proof exchange remains required. For callback
+flows use `completeAuthorizationCallback`'s optional `ensureMemberEnrollment`
+hook. It runs after the one-time provider proof is durably staged, with a stable
+`idempotencyKey` preserved across retries. Verify the staged proof's signature,
+issuer, audience, algorithm, expiry and nonce, then call `enrollExternalMember`
+with its exact `sub`. Return that result from the hook. The helper checks that
+the resulting authenticated session resolves to the enrolled account holder.
+Do not put a fallible enrollment call inside `exchangeProviderCode`, before
+the provider result has been staged. A version conflict requires reviewing the
+changed registration and starting a new authorization flow, not blind retries.
+
+```ts
+const completion = await memberAuth.completeAuthorizationCallback({
+  ...callbackInput,
+  ensureMemberEnrollment: async ({ proofToken, idempotencyKey }) => {
+    // This application function performs full JOSE and exact nonce validation.
+    const verified = await verifyRegisteredProviderProof(proofToken);
+    return memberAuth.enrollExternalMember({
+      externalSub: verified.sub,
+      applicationConfigVersion: registration.config_version,
+      idempotencyKey,
+    });
+  },
+});
+```
+
+The verifier and `registration` are application prerequisites in this example,
+not SDK-provided provider validation or discovery functions. The public endpoint
+is `POST /v1/member-auth/enrollments`; it accepts no caller-selected account
+holder, tenant, issuer namespace, email or permissions. Enrollment alone never
+qualifies fresh action assurance, signing authority or settlement.
+
 ### Account Center and action callbacks
 
+Direct Account Center starts accept `security`, `sessions`, or
+`wallet_readiness`. Resource-bound actions start through the member action
+flow; their shared callback result may contain the `action` intent. Refresh
+preserves the session ID, account holder, and provider subject. A changed
+identity is rejected before replacing stored credentials, including when
+separate session validation is disabled for an immediate business request.
+
 Account Center accepts a same-origin `applicationReturnUri` and preserves it
 through successful callback recovery. Member actions separately accept
 `applicationReviewUri` for cancellation or expiry and `applicationReturnUri`
@@ -344,6 +530,10 @@ Business requests use `no-store` and reject redirects so credentials cannot
 follow a redirect. Network failures preserve the application session. Reuse the
 original idempotency key when reconciling an uncertain write.
 
+`resolved.resources.self.profile()` returns the current member's profile,
+including email and name. These fields are display metadata, not authentication
+proof. Read the profile when displaying it instead of caching it in the session.
+
 `resolved.resources.self.verification()` returns the member's verification
 requirements and sessions through the public self-verification operation.
 `resolved.resources.self.uploadAvatar(image)` performs presign, object upload,
@@ -351,7 +541,7 @@ confirmation, and refreshed avatar lookup. Pass a nonempty PNG, JPEG, WebP, or G
 `Blob` of at most 5 MiB. Storage receives only the image bytes and their content
 headers, never bearer credentials, request signatures, member context, or cookies.
 The helper rejects redirects, expired capabilities, URL credentials, and non-HTTPS
-storage URLs (localhost HTTP is permitted for local development). It does not
+storage URLs (HTTP on `localhost` or `127.0.0.1` is permitted for local development). It does not
 retry an upload. `XKOVAUploadError` identifies the object-storage stage without
 exposing the signed URL; API failures retain `XKOVAApiError` metadata.
 
@@ -371,7 +561,44 @@ Durable application cookies use the host-only `__Host-` prefix, `Secure`, `HttpO
 
 The publishable key is a non-secret application registration identifier. It grants no member or tenant authority by itself. The registered application pins tenant, workspace, environment, provider kind, issuer, audience, origins, redirects, and session policy, and must also match the authenticated workspace principal.
 
-## Cancellation and deadlines
+### Recover an existing member payment
+
+Read recovery state through the resolved member resources:
+
+```ts
+const recovery = await resolved.resources.payments.recovery(paymentId);
+// Call only after the member confirms cancellation in your app.
+if (recovery.can_cancel) {
+  await resolved.resources.payments.cancelForMember(paymentId);
+}
+```
+
+The API permits reads by the sender or recipient. Only the sender can cancel
+or continue. The API principal needs `payment.read` and `payment.cancel`
+permissions for these operations. Your BFF must validate the session, exact
+Origin, and CSRF token before cancellation. Cancellation does not require a
+passkey because it sends no value.
+
+When `can_continue` is true, use `beginMemberAction()` with
+`resourceType: 'payment'`, the existing `resourceId`, and `action: 'sign'`.
+Complete fresh authorization through the registered provider. Keep the original
+amount, recipient, fees, and deadline. Do not create a second payment or reuse
+an expired signing credential. Recovery uses the payment ID, so a new valid
+session for the same member can recover it without the original form draft.
+
+`approval_expired` means the signing window has closed. It remains cancellable
+until a signature has been accepted. After acceptance, `processing` disables
+both actions. `cancelled`, `completed`, and `failed` are separate outcomes;
+retain all three in history. These actions apply to payments; escrow
+cancellation has its own authorization and settlement rules.
+
+Availability can change between a read and a click. After a conflict or an
+uncertain cancellation response, read recovery state again. Repeating an
+already completed member cancellation returns the cancelled payment. Aborting
+an HTTP request or cancelling an authorization ceremony does not cancel the
+payment.
+
+## Request cancellation and deadlines
 
 Set `timeoutMs` on the client for a default request deadline. Mutation options and workflow polling also accept an `AbortSignal`:
 
@@ -386,6 +613,33 @@ await xkova.payments.cancel('pay_...', {
 
 The SDK does not automatically retry writes. Use `withRetry` with a stable idempotency key when retry behavior is appropriate for your application.
 
+## Product enrollment
+
+After a member accepts your displayed terms, call
+`resources.self.acceptProductEnrollment(product, { terms_version })` from the
+BFF. Select the product and terms version on your server. Read the saved result
+with `resources.self.productEnrollment(product)` when the member returns.
+Acceptance does not require an `Idempotency-Key` header. Repeating the same
+acceptance preserves its timestamp. Changed terms or credit parameters with the
+same product are rejected.
+
+Sandbox applications can include `sandbox_credit: { token_deployment_id,
+amount }` to issue a test-token welcome credit. Use an active dUSDC deployment.
+The credit is issued once per member, workspace, and product, across application
+registrations. The daily workspace budget is 1000 dUSDC. Keep amounts and token
+selection in the BFF, and give each product a stable identifier.
+
+For Hosted Auth, set `require_passkey: true` to hold activation and the credit
+until the member has an active passkey and has acknowledged recovery codes.
+`setup_required` means terms are saved and security setup remains incomplete.
+Open Account Center with the `security` intent, then read the enrollment again
+on return. The setup requirement is fixed when the enrollment is accepted.
+
+Poll the enrollment after acceptance. `opening` means delivery is pending;
+`active` means the credit has a successful receipt and an indexed balance.
+`requires_review` needs operator investigation. Do not create another product
+identifier to retry an uncertain credit. Credits do not debit bank accounts.
+
 ## Errors
 
 `XKOVAApiError.retryAfter` preserves the upstream `Retry-After` header when
@@ -405,6 +659,40 @@ try {
 }
 ```
 
+## Treasury vaults and transfer proposals
+
+Use `client.treasury` from a trusted backend with the workspace's explicitly
+granted treasury scopes and roles. Discover the chain and eligible assets before
+creating a vault or proposal. An existing same-chain vault retains its real
+owner set and threshold.
+
+```ts
+import { isHeldApproval } from '@xkova/sdk';
+
+const vaults = await xkova.treasury.listWallets();
+const proposal = await xkova.treasury.getTransfer('trf_...');
+const counterparties = await xkova.treasury.listCounterparties({ limit: 20 });
+```
+
+Vault and counterparty setup can return a governance hold. Check `isHeldApproval`
+before reading entity fields. Keep the original request and idempotency key;
+resume through normal policy after independently eligible approvers complete the
+required approval. The SDK does not approve, sign or retry a held operation.
+
+`draftTransfer` creates a proposal. `getTransfer` reads its frozen signing context
+and current quorum. Each eligible owner produces their own signature over that
+exact Safe transaction. `submitTransferSignature` submits an existing signature;
+it does not create a wallet or sign on anyone's behalf. `executeTransfer` retains
+current role, signer, nonce, quorum and policy checks. A returned relay result is
+not settlement; read the proposal until its actual confirmed or failed outcome.
+After a timeout, reconcile the existing proposal before creating another one.
+
+The API key's attributed staff ID is audit metadata, not a per-human session or
+permission to bootstrap a staff wallet. This namespace does not expose Console
+credentials, staff-wallet bootstrap credentials, or raw private-key material.
+The supported workforce authentication and independent signer ceremonies remain
+separate requirements for a complete customer treasury application.
+
 ## Webhooks and generated types
 
 ```ts
@@ -412,7 +700,19 @@ import { verifyWebhookSignature } from '@xkova/sdk/webhook';
 import type { components, paths } from '@xkova/sdk/types';
 ```
 
-Pass the raw request body to `verifyWebhookSignature`. The `types` subpath contains only the customer operations included in this SDK release.
+Pass the raw request body to `verifyWebhookSignature`. Import request and response types from `@xkova/sdk/types`.
+
+Each `v1` signature must contain exactly 64 lowercase hexadecimal characters.
+Malformed candidates are rejected without truncation; valid multiple-signature
+rotation headers remain supported.
+
+`tokenDeploy` submits once and observes the returned token until it is active.
+Deployment operations cannot be read through the generic operation endpoint.
+`tokenMint` waits for its exact mint operation to be confirmed before returning
+the token. An already-active token does not establish mint success.
+Cancellation, pending exhaustion, a failed operation, or an uncertain response
+never causes these helpers to submit another mutation. Reconcile the retained
+token or operation before deciding whether to retry explicitly.
 
 The package also exposes `@xkova/sdk/rwa-verify` for offline RWA transparency proof verification and `@xkova/sdk/abi` for the documented customer contract ABIs.
 
@@ -432,14 +732,6 @@ idempotency, and settlement. It links the public customer OpenAPI and expanded
 documentation. Installed declarations determine the methods available in your
 version; live documentation may describe a newer release.
 
-## Thirdweb and dependencies
-
-The only direct runtime dependency is `viem`, used for offline RWA signature
-verification. This SDK does not import Thirdweb. The optional `@xkova/browser`
-browser companion has no runtime dependencies. XKOVA manages wallet signing,
-and API provider metadata may name Thirdweb. You do not need to install its SDK
-or obtain Thirdweb credentials.
-
 ## Contributing
 
 Run `pnpm check` from the source repository root before committing. The

package/dist/abi.d.ts

@@ -336,6 +336,14 @@ export declare const erc20XGaslessAbi: readonly [{
         readonly name: "";
         readonly type: "string";
         readonly internalType: "string";
+    }, {
+        readonly name: "";
+        readonly type: "uint8";
+        readonly internalType: "uint8";
+    }, {
+        readonly name: "";
+        readonly type: "address";
+        readonly internalType: "address";
     }, {
         readonly name: "";
         readonly type: "address";
@@ -362,6 +370,10 @@ export declare const erc20XGaslessAbi: readonly [{
         readonly name: "_symbol";
         readonly type: "string";
         readonly internalType: "string";
+    }, {
+        readonly name: "decimals_";
+        readonly type: "uint8";
+        readonly internalType: "uint8";
     }, {
         readonly name: "defaultAdmin";
         readonly type: "address";
@@ -370,6 +382,10 @@ export declare const erc20XGaslessAbi: readonly [{
         readonly name: "minter";
         readonly type: "address";
         readonly internalType: "address";
+    }, {
+        readonly name: "burner";
+        readonly type: "address";
+        readonly internalType: "address";
     }, {
         readonly name: "pauser";
         readonly type: "address";
@@ -1062,6 +1078,10 @@ export declare const erc20XGaslessAbi: readonly [{
     readonly type: "error";
     readonly name: "InvalidAddress";
     readonly inputs: readonly [];
+}, {
+    readonly type: "error";
+    readonly name: "InvalidDecimals";
+    readonly inputs: readonly [];
 }, {
     readonly type: "error";
     readonly name: "InvalidImplementation";
@@ -5482,6 +5502,14 @@ export declare const tokenizationAbis: {
             readonly name: "";
             readonly type: "string";
             readonly internalType: "string";
+        }, {
+            readonly name: "";
+            readonly type: "uint8";
+            readonly internalType: "uint8";
+        }, {
+            readonly name: "";
+            readonly type: "address";
+            readonly internalType: "address";
         }, {
             readonly name: "";
             readonly type: "address";
@@ -5508,6 +5536,10 @@ export declare const tokenizationAbis: {
             readonly name: "_symbol";
             readonly type: "string";
             readonly internalType: "string";
+        }, {
+            readonly name: "decimals_";
+            readonly type: "uint8";
+            readonly internalType: "uint8";
         }, {
             readonly name: "defaultAdmin";
             readonly type: "address";
@@ -5516,6 +5548,10 @@ export declare const tokenizationAbis: {
             readonly name: "minter";
             readonly type: "address";
             readonly internalType: "address";
+        }, {
+            readonly name: "burner";
+            readonly type: "address";
+            readonly internalType: "address";
         }, {
             readonly name: "pauser";
             readonly type: "address";
@@ -6208,6 +6244,10 @@ export declare const tokenizationAbis: {
         readonly type: "error";
         readonly name: "InvalidAddress";
         readonly inputs: readonly [];
+    }, {
+        readonly type: "error";
+        readonly name: "InvalidDecimals";
+        readonly inputs: readonly [];
     }, {
         readonly type: "error";
         readonly name: "InvalidImplementation";

package/dist/abi.js

@@ -443,6 +443,16 @@ export const erc20XGaslessAbi = [
                 "type": "string",
                 "internalType": "string"
             },
+            {
+                "name": "",
+                "type": "uint8",
+                "internalType": "uint8"
+            },
+            {
+                "name": "",
+                "type": "address",
+                "internalType": "address"
+            },
             {
                 "name": "",
                 "type": "address",
@@ -476,6 +486,11 @@ export const erc20XGaslessAbi = [
                 "type": "string",
                 "internalType": "string"
             },
+            {
+                "name": "decimals_",
+                "type": "uint8",
+                "internalType": "uint8"
+            },
             {
                 "name": "defaultAdmin",
                 "type": "address",
@@ -486,6 +501,11 @@ export const erc20XGaslessAbi = [
                 "type": "address",
                 "internalType": "address"
             },
+            {
+                "name": "burner",
+                "type": "address",
+                "internalType": "address"
+            },
             {
                 "name": "pauser",
                 "type": "address",
@@ -1376,6 +1396,11 @@ export const erc20XGaslessAbi = [
         "name": "InvalidAddress",
         "inputs": []
     },
+    {
+        "type": "error",
+        "name": "InvalidDecimals",
+        "inputs": []
+    },
     {
         "type": "error",
         "name": "InvalidImplementation",

package/dist/client.d.ts

@@ -13,6 +13,7 @@ import { RampsResource } from './resources/ramps.js';
 import { RwaResource } from './resources/rwa.js';
 import { TenantResource } from './resources/tenant.js';
 import { TokenizationResource } from './resources/tokenization.js';
+import { TreasuryResource } from './resources/treasury.js';
 import { TransactionsResource } from './resources/transactions.js';
 import { WalletsResource } from './resources/wallets.js';
 import { WebhooksResource } from './resources/webhooks.js';
@@ -47,6 +48,7 @@ export interface XKOVAMutationOptions extends XKOVARequestControl {
 export declare class XKOVAClient {
     private readonly config;
     private readonly memberContext?;
+    private readonly workforceContext?;
     private readonly apiBaseUrl;
     private readonly fetchImpl;
     private constructor();
@@ -65,6 +67,8 @@ export declare class XKOVAClient {
     get rwa(): RwaResource;
     get tenant(): TenantResource;
     get tokenization(): TokenizationResource;
+    /** Tenant treasury operations retain server-side roles, governance and signer checks. */
+    get treasury(): TreasuryResource;
     get transactions(): TransactionsResource;
     get wallets(): WalletsResource;
     get webhooks(): WebhooksResource;