You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|`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. |
26
26
|`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`|
28
28
29
29
<Note>
30
30
The hosted services are best suited for prototyping. Self-host the Auth
31
31
Service and Login Server for production traffic or when you need custom
32
32
configuration.
33
33
</Note>
34
34
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.
description: "Configure payment system for the Lit JS SDK"
2
+
title: 'Payment Manager Setup'
3
+
description: 'Configure payment system for the Lit JS SDK'
4
4
---
5
5
6
6
<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.
9
13
</Warning>
10
14
11
15
<Note>
@@ -23,10 +27,11 @@ description: "Configure payment system for the Lit JS SDK"
23
27
24
28
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:
25
29
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).
The Payment Manager lets one account sponsor the execution costs of another. See the following full lifecycle: Alice funds her ledger, delegates limits to Bob, Bob spends from Alice's balance, and Alice later revokes access. The snippets below mirror that scenario so you can recreate it locally.
108
+
<Steps>
109
+
<Steptitle="Define spending limit">
103
110
104
-
-`Alice` is the sponsor. She configures spending limits and delegates them to Bob.
105
-
-`Bob` is the delegate. He signs with his PKP and provides `userMaxPrice` that fits within Alice's limits.
106
-
- When Bob spends funds, Alice's ledger balance decreases.
107
-
- Alice can immediately revoke Bob's access; further requests then fail.
111
+
Define spending limits for the users you want to sponsor (values are in wei).
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)
117
120
});
121
+
```
118
122
119
-
// 1. Configure Alice's spending restrictions for all delegates
120
-
awaitalicePaymentManager.setRestriction({
121
-
totalMaxPrice: '1000000000000000000', // 1 ETH (wei string)
122
-
requestsPerPeriod: '100',
123
-
periodSeconds: '5',
124
-
});
123
+
</CodeGroup>
125
124
126
-
// 2. Delegate access to Bob's EOA address
127
-
awaitalicePaymentManager.delegatePaymentsBatch({
128
-
userAddresses: [bobAddress],
129
-
});
125
+
</Step>
126
+
127
+
<Steptitle="Delegate users">
128
+
129
+
With restrictions set, delegate one or more users to spend from your payer wallet.
130
+
131
+
<CodeGroup>
130
132
131
-
// 3. Optionally inspect Alice's ledger balance before Bob spends
132
-
const before =awaitalicePaymentManager.getBalance({
133
-
userAddress: aliceViemAccount.address,
133
+
```typescript
134
+
awaitpaymentManager.delegatePaymentsBatch({
135
+
userAddresses: ['0xAlice...', '0xBob...'],
134
136
});
135
-
console.log('Alice balance before Bob signs:', before.raw.availableBalance);
136
137
```
137
138
138
-
When Bob signs, the execution is charged against Alice's ledger (as long as Bob's `userMaxPrice` is within Alice's configured limit).
139
+
</CodeGroup>
140
+
</Step>
141
+
142
+
<Steptitle="(Optional) Inspect Balance">
143
+
144
+
Optionally inspect Payer/Sponsor Ledger balance
145
+
146
+
<CodeGroup>
147
+
```ts
148
+
const balance =awaitpaymentManager.getBalance({
149
+
userAddress: viemAccount.address,
150
+
});
151
+
```
152
+
</CodeGroup>
153
+
</Step>
154
+
155
+
<Steptitle="Remove users (optional)">
156
+
157
+
Undelegate users when you no longer want to sponsor them.
158
+
159
+
<CodeGroup>
139
160
140
161
```typescript
141
-
awaitlitClient.chain.ethereum.pkpSign({
142
-
authContext: bobAuthContext, // Created with Bob's account
143
-
pubKey: bobPkpPublicKey,
144
-
toSign: 'Hello, world!',
145
-
userMaxPrice: 200000000000000000n, // 0.2 ETH in Wei
162
+
awaitpaymentManager.undelegatePaymentsBatch({
163
+
userAddresses: ['0xAlice...'],
146
164
});
147
165
```
148
166
149
-
After Bob signs, Alice's balance drops. She can revoke Bob immediately using `undelegatePaymentsBatch`. Subsequent attempts by Bob will fail.
167
+
</CodeGroup>
150
168
151
-
```typescript
152
-
// 4. Confirm Alice's balance decreased
153
-
const after =awaitalicePaymentManager.getBalance({
154
-
userAddress: aliceViemAccount.address,
169
+
</Step>
170
+
</Steps>
171
+
172
+
## **Alternatively**
173
+
174
+
Manage delegation via the hosted or self-hosted Auth Service (see [Auth Services setup](/sdk/getting-started/auth-services) for the full flow).
175
+
176
+
## After Payment Delegation
177
+
178
+
**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.
179
+
180
+
<Note>
181
+
ℹ️ `userMaxPrice` is recommended for sponsored sessions, typically the same value or less than the the restriction the sponsor set; optional guardrail when self-funded.
Leverage the hosted Auth Service to manage delegation without exposing private keys in your application:
167
-
168
-
-`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.
169
-
-`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.
208
+
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:
170
209
171
-
> The legacy capacity-credit minting flow has been removed. Payment delegation now interacts directly with the Payment Manager contracts.
210
+
- Call `authService.registerPayer` (hosted or self-hosted) to derive a payer wallet + `payerSecretKey`.
211
+
- Call `authService.delegateUsers` (`/add-users`) to sponsor a list of user addresses.
212
+
- Or skip the service entirely and use the Payment Manager methods directly (example below).
- 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