Skip to content

Commit 50ca388

Browse files
authored
Merge branch 'naga' into feature/jss-76-bug-request-id-should-be-included-inside-the-thrown-error
2 parents 0b6385d + 401eefc commit 50ca388

File tree

20 files changed

+3269
-1813
lines changed

20 files changed

+3269
-1813
lines changed

.changeset/giant-adults-wonder.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
---
2+
'@lit-protocol/contracts': patch
3+
'@lit-protocol/e2e': patch
4+
'@lit-protocol/auth': patch
5+
'@lit-protocol/auth-helpers': patch
6+
'@lit-protocol/auth-services': patch
7+
'@lit-protocol/constants': patch
8+
'@lit-protocol/lit-client': patch
9+
'@lit-protocol/networks': patch
10+
---
11+
12+
Update the naga-dev staking address. users are expected to reinstall the SDK to apply this patch to continue using the naga-dev network.

docs/sdk/getting-started/auth-services.mdx

Lines changed: 20 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -24,14 +24,33 @@ Lit hosts default Auth Service instances so you can build without deploying infr
2424
| ----------- | ------------------------------------------- | ------------------------------ | ----- |
2525
| `naga-dev` | `https://naga-dev-auth-service.getlit.dev` | `https://login.litgateway.com` | Use Lit's hosted endpoints while you prototype. Configure your SDK or environment variables with the URLs in this table. |
2626
| `naga-test` | `https://naga-test-auth-service.getlit.dev` | `https://login.litgateway.com` | Start with the hosted endpoints for staging, then switch to your own infrastructure as you scale. |
27-
| `naga` | `Run your own (recommended)` | `Run your own (recommended)` | Lit does not operate public Auth Service or Login Server endpoints for `naga` |
27+
| `naga` | `Run your own (recommended)` | `Run your own (recommended)` | Lit does not (yet) operate public Auth Service or Login Server endpoints for `naga` |
2828

2929
<Note>
3030
The hosted services are best suited for prototyping. Self-host the Auth
3131
Service and Login Server for production traffic or when you need custom
3232
configuration.
3333
</Note>
3434

35+
## Payment Delegation APIs
36+
37+
The Auth Service also exposes lightweight endpoints that sponsor user requests on the network. These are the same APIs the Lit SDK calls when you use `litClient.authService.registerPayer` / `delegateUsers` from the Payment Manager guide.
38+
39+
- `POST /register-payer`
40+
- Headers: `x-api-key`.
41+
- Behaviour: generates a random `payerSecretKey`, hashes it with the API key, and derives a child wallet from `LIT_DELEGATION_ROOT_MNEMONIC`.
42+
- Response: `{ success, payerWalletAddress, payerSecretKey }`. The service **does not** persist the secret—you must store it securely (KMS, vault, etc.).
43+
- Rotation: call the endpoint again with the same API key to rotate the secret and derive a new child wallet.
44+
- `POST /add-users`
45+
- Headers: `x-api-key`, `payer-secret-key`; body is a JSON array of user addresses.
46+
- Behaviour: recomputes the same child wallet on the fly and calls `PaymentManager.delegatePaymentsBatch` so the payer sponsors those users.
47+
48+
<Tip>
49+
Running the Auth Service yourself keeps the derivation mnemonic and payer secrets inside your infrastructure. The Lit-hosted instance is great for quick starts, but you remain responsible for storing the returned `payerSecretKey`.
50+
</Tip>
51+
52+
If you prefer not to run an Auth Service at all, you can still sponsor users manually: create a payer wallet, fund it, and call `paymentManager.delegatePayments*` directly from your backend. See [Payment Manager Setup](/sdk/getting-started/payment-manager-setup#sponsoring-your-users-capacity-delegation-replacement) for sample code.
53+
3554

3655
### Install the SDK
3756

docs/sdk/getting-started/payment-manager-setup.mdx

Lines changed: 121 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,15 @@
11
---
2-
title: "Payment Manager Setup"
3-
description: "Configure payment system for the Lit JS SDK"
2+
title: 'Payment Manager Setup'
3+
description: 'Configure payment system for the Lit JS SDK'
44
---
55

66
<Warning>
7-
❗️ Currently free on the dev network, so no need to deposit funds. More
8-
details coming soon for test and production networks.
7+
❗️ Payment status by network:
8+
- **naga-dev** – usage is currently free; no deposits required.
9+
- **naga-test** – payments are enabled using test tokens (see faucet link
10+
below).
11+
- **Mainnet** – coming soon; mainnet payment details will be announced
12+
shortly.
913
</Warning>
1014

1115
<Note>
@@ -23,10 +27,11 @@ description: "Configure payment system for the Lit JS SDK"
2327

2428
The Payment Manager demonstrates Lit Protocol's payment system - a billing system for decentralised cryptographic services. Users pay for compute resources on the Lit network to access core services like:
2529

26-
- Encryption/Decryption - Secure data with programmable access control
27-
- PKP Signing - Cryptographic keys that can sign transactions based on conditions
28-
- Lit Actions - Serverless functions with cryptographic capabilities
29-
Similar to how you pay AWS for cloud computing, this\system ensures the decentralised network can sustain itself and pay node operators. You can deposit funds, request withdrawals with security delays, and manage balances for yourself or other users (enabling applications to sponsor their users' costs for better UX).
30+
- [Encryption/Decryption](/sdk/auth-context-consumption/encrypt-and-decrypt) - Secure data with programmable access control.
31+
- [PKP Signing](/sdk/auth-context-consumption/pkp-sign) - Cryptographic keys that can sign transactions based on conditions.
32+
- [Lit Actions](/sdk/auth-context-consumption/execute-js) - Serverless functions with cryptographic capabilities.
33+
34+
Similar to how you pay AWS for cloud computing, this system ensures the decentralised network can sustain itself and pay node operators. Each payer keeps a balance in the on-chain Lit Ledger contract funded with `$LITKEY` (or `$tstLPX` on testnet), which the network debits as requests execute. You can deposit funds, request withdrawals with security delays, and manage balances for yourself or other users (enabling applications to sponsor their users' costs for better UX).
3035

3136
<Steps>
3237
<Step title="Payment Manager Setup">
@@ -40,8 +45,9 @@ const litClient = await createLitClient({ network: nagaTest });
4045

4146
// 2. Get PaymentManager instance (requires account for transactions)
4247
const paymentManager = await litClient.getPaymentManager({
43-
account: yourAccount // viem account instance
48+
account: yourAccount // viem account instance
4449
});
50+
4551
````
4652

4753
</Step>
@@ -59,7 +65,7 @@ const { data: myAccount } = useWalletClient();
5965
6066
```typescript viem/accounts
6167
// 1. import the privateKeyToAccount function from viem/accounts
62-
import { privateKeyToAccount } from "viem/accounts";
68+
import { privateKeyToAccount } from 'viem/accounts';
6369

6470
// 2. Convert your private key to a viem account object that can be used for payment operations.
6571
const myAccount = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`);
@@ -74,7 +80,7 @@ const myAccount = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`);
7480
```typescript Deposit funds to your own account
7581
// 1. Deposit funds to your own account
7682
const result = await paymentManager.deposit({
77-
amountInEth: "0.1",
83+
amountInEth: '0.1',
7884
});
7985

8086
console.log(`Deposit successful: ${result.hash}`);
@@ -84,8 +90,8 @@ console.log(`Deposit successful: ${result.hash}`);
8490
```typescript Deposit for another user
8591
// 1. Deposit funds for another user
8692
const result = await paymentManager.depositForUser({
87-
userAddress: "0x742d35Cc6638Cb49f4E7c9ce71E02ef18C53E1d5",
88-
amountInEth: "0.05",
93+
userAddress: '0x742d35Cc6638Cb49f4E7c9ce71E02ef18C53E1d5',
94+
amountInEth: '0.05',
8995
});
9096

9197
console.log(`Deposit successful: ${result.hash}`);
@@ -97,14 +103,101 @@ console.log(`Deposit successful: ${result.hash}`);
97103

98104
</Steps>
99105

100-
## Auth Service API Endpoints
106+
## Sponsoring Your Users
107+
108+
<Steps>
109+
<Step title="Define spending limit">
110+
111+
Define spending limits for the users you want to sponsor (values are in wei).
112+
113+
<CodeGroup>
114+
115+
```typescript
116+
await paymentManager.setRestriction({
117+
totalMaxPrice: '1000000000000000000', // 1 ETH equivalent limit
118+
requestsPerPeriod: '100', // max number of sponsored requests in a period
119+
periodSeconds: '3600', // rolling window (1 hour in this example)
120+
});
121+
```
122+
123+
</CodeGroup>
124+
125+
</Step>
101126

102-
Leverage the hosted Auth Service to manage delegation without exposing private keys in your application:
127+
<Step title="Delegate users">
103128

104-
- `POST /register-payer` - Send your `x-api-key` header to receive a delegated payer address and `payerSecretKey`. Persist this secret securely; it is required for all future delegation calls.
105-
- `POST /add-users` - Provide headers `x-api-key` and `payer-secret-key` plus a JSON body containing an array of user addresses. The Auth Service uses the Payment Manager internally to delegate payments to each address in a single transaction.
129+
With restrictions set, delegate one or more users to spend from your payer wallet.
106130

107-
> The legacy capacity-credit minting flow has been removed. Payment delegation now interacts directly with the Payment Manager contracts.
131+
<CodeGroup>
132+
133+
```typescript
134+
await paymentManager.delegatePaymentsBatch({
135+
userAddresses: ['0xAlice...', '0xBob...'],
136+
});
137+
```
138+
139+
</CodeGroup>
140+
141+
</Step>
142+
143+
<Step title="Remove users (optional)">
144+
145+
Undelegate users when you no longer want to sponsor them.
146+
147+
<CodeGroup>
148+
149+
```typescript
150+
await paymentManager.undelegatePaymentsBatch({
151+
userAddresses: ['0xAlice...'],
152+
});
153+
```
154+
155+
</CodeGroup>
156+
157+
</Step>
158+
</Steps>
159+
160+
## **Alternatively**
161+
162+
Manage delegation via the hosted or self-hosted Auth Service (see [Auth Services setup](/sdk/getting-started/auth-services) for the full flow).
163+
164+
## After Payment Delegation
165+
166+
**Users decrypt as normal** – we still call `litClient.decrypt` with an auth context; the network draws fees from the delegated payer instead of the user’s wallet.
167+
168+
<Note>
169+
ℹ️ `userMaxPrice` is recommended for sponsored sessions, typically the same value or less than the the restriction the sponsor set; optional guardrail when self-funded.
170+
</Note>
171+
172+
```typescript highlight={18}
173+
// Client-side decrypt with sponsored payments
174+
const authContext = await authManager.createEoaAuthContext({
175+
litClient,
176+
config: { account: walletClient },
177+
authConfig: {
178+
resources: [
179+
['access-control-condition-decryption', '*'],
180+
['lit-action-execution', '*'],
181+
],
182+
},
183+
});
184+
185+
const response = await litClient.decrypt({
186+
data: encryptedData,
187+
unifiedAccessControlConditions: accs,
188+
authContext,
189+
chain: 'ethereum',
190+
userMaxPrice: 1000000000000000000n,
191+
});
192+
```
193+
194+
## Auth Service API Endpoints
195+
196+
Leverage the hosted Auth Service to manage delegation without exposing private keys in your application. Full request/response details live in the [Auth Services setup guide](/sdk/getting-started/auth-services#payment-delegation-apis). In practice you will:
197+
198+
- Call `authService.registerPayer` (hosted or self-hosted) to derive a payer wallet + `payerSecretKey`.
199+
- Call `authService.delegateUsers` (`/add-users`) to sponsor a list of user addresses.
200+
- Or skip the service entirely and use the Payment Manager methods directly (example below).
108201

109202
```typescript
110203
import { createLitClient } from '@lit-protocol/lit-client';
@@ -113,40 +206,31 @@ import { nagaTest } from '@lit-protocol/networks';
113206
// 1. Create the Lit client for the naga-test environment
114207
const litClient = await createLitClient({ network: nagaTest });
115208

116-
const authServiceBaseUrl = 'https://naga-test-auth-service.example.com';
117-
const apiKey = process.env.LIT_API_KEY!;
209+
const authServiceBaseUrl = 'https://naga-test-auth-service.getlit.dev/';
210+
const apiKey = process.env.YOUR_AUTH_SERVICE_API_KEY!;
118211

119212
// 3. Register a payer wallet (store the secret securely server-side)
120213
const registerResponse = await litClient.authService.registerPayer({
121-
authServiceBaseUrl,
122-
apiKey,
214+
authServiceBaseUrl,
215+
apiKey,
123216
});
124217

125218
console.log('Payer wallet:', registerResponse.payerWalletAddress);
126219
console.log('Payer secret (store securely!):', registerResponse.payerSecretKey);
127220

128221
// 4. Later on, delegate payments for multiple users using the saved secret
129222
const delegateResponse = await litClient.authService.delegateUsers({
130-
authServiceBaseUrl,
131-
apiKey,
132-
payerSecretKey: registerResponse.payerSecretKey,
133-
userAddresses: [
134-
'0x1234...abcd',
135-
'0xabcd...1234',
136-
],
223+
authServiceBaseUrl,
224+
apiKey,
225+
payerSecretKey: registerResponse.payerSecretKey,
226+
userAddresses: ['0x1234...abcd', '0xabcd...1234'],
137227
});
138228

139229
console.log('Delegation submitted with tx hash:', delegateResponse.txHash);
140230

141231
// 5. Continue to use the same payer secret for future delegation calls
142-
````
232+
```
143233

144234
### How the Auth Service derives payer wallets
145235

146-
- The service holds a single root mnemonic (`LIT_DELEGATION_ROOT_MNEMONIC`).
147-
- `/register-payer` combines the `x-api-key` header with a freshly generated `payerSecretKey`. That pair is hashed into a deterministic derivation index, which is then used with the root mnemonic to derive a unique child wallet.
148-
- The response includes the derived wallet address and the random `payerSecretKey`. The server does not store this secret; you must persist it securely on the client side.
149-
- Later, `/add-users` expects both headers (`x-api-key` and `payer-secret-key`). The service recomputes the same derivation index and wallet on the fly, so the same header pair always maps to the same child wallet.
150-
- Calling `/register-payer` again with the same API key issues a new random `payerSecretKey`, which leads to a different child wallet. Choose whether to rotate secrets or keep the original one depending on your application needs.
151-
152-
![](https://www.plantuml.com/plantuml/png/XPAn3jCm48PtFyMfKw8IiKSAQcab1a1K58c1CXpEaLWaJcHVIlFs6DkKcBHYYy-Vl_Floyuo6fxwJh3YZc0_SGjdCbSb2KuuzwGPZjHHWwm6BSJeS2NLYAw-ENJAxMy0BOJFT7ifyz3lGbodv3l5qG3lKMD3nlFn-ndh6RTyr3lSFTN5MYo96Xc_eINOh8F2OT1iKFeUzuKGLGKVgL6MoS28CnceAX5lNhnQ1YpXzE7y2LwQY1SUl-ZiLk2eYXyqvsA1hqw_8Kq6cKARCqb3VD57CkfAy1ExZXY-cw67NbC_Q2LX2quCJfnwdJXSi0ogp_xilguDMNlH2_rRcdt2-0m4aoLZ_viGwxhmv3BSYz2iiDuSAXxwydMLEmwaX8RYBBDSnABR_plY4fmCcToZEbUgMM1Ub0uxGoc7INCk0XNJf509Ibj6pGfvPVyNhUCZnRfzZIpRp4VCHGgxu_TVo1zSlAxuim75WoPy0qEIrCWhPJeBZxPeswUpjvEKP2rix-IET3trtIy0)
236+
- For hosted or self-hosted deployments, see the derivation and rotation notes in the [Auth Services guide](/sdk/getting-started/auth-services#payment-delegation-apis). Manual deployments can always provision and delegate entirely via the `PaymentManager` helper without touching these endpoints.

0 commit comments

Comments
 (0)