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
Lit Protocol has established an initial governance system to guide and organize its development and operations. This system exists to manage decision-making related to the core protocol, the infrastructure that supports it, and the broader ecosystem of applications built on top of it.
Lit Protocol is secured and operated by a decentralized network of validator nodes. These nodes are responsible for executing the threshold cryptographic operations that underpin the core functionality of the network, including signing, encryption, decryption, and private compute via Lit Actions.
6
12
7
13
Each node participates in threshold signature multi-party computation (TSS MPC) protocols and operates inside a confidential compute environment (TEE), ensuring that no single operator can access plaintext key material or violate policy constraints.
@@ -14,4 +20,4 @@ A staking and delegation contest will be run to select the genesis validator set
14
20
15
21
To whitelist your node, visit https://staking.litprotocol.com/
16
22
17
-
Refer to the next page for details on hardware specs, minimum requirements, and operational guidelines for node operators.
23
+
Refer to the next page for details on hardware specs, minimum requirements, and operational guidelines for node operators.
Copy file name to clipboardExpand all lines: docs/sdk/getting-started/auth-services.mdx
+19Lines changed: 19 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -56,6 +56,25 @@ Lit hosts default Auth Service instances so you can build without deploying infr
56
56
configuration.
57
57
</Note>
58
58
59
+
## Payment Delegation APIs
60
+
61
+
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.
62
+
63
+
-`POST /register-payer`
64
+
- Headers: `x-api-key`.
65
+
- Behaviour: generates a random `payerSecretKey`, hashes it with the API key, and derives a child wallet from `LIT_DELEGATION_ROOT_MNEMONIC`.
66
+
- Response: `{ success, payerWalletAddress, payerSecretKey }`. The service **does not** persist the secret—you must store it securely (KMS, vault, etc.).
67
+
- Rotation: call the endpoint again with the same API key to rotate the secret and derive a new child wallet.
68
+
-`POST /add-users`
69
+
- Headers: `x-api-key`, `payer-secret-key`; body is a JSON array of user addresses.
70
+
- Behaviour: recomputes the same child wallet on the fly and calls `PaymentManager.delegatePaymentsBatch` so the payer sponsors those users.
71
+
72
+
<Tip>
73
+
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`.
74
+
</Tip>
75
+
76
+
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>
@@ -22,9 +26,9 @@ description: "Configure payment system for the Lit JS SDK"
22
26
23
27
The Payment Manager handles Lit Protocol's payment system - a billing mechanism for decentralized cryptographic services. Users deposit funds to pay for compute resources when accessing core network operations:
24
28
25
-
-**Encryption/Decryption** - Encrypt data that only authorized users or conditions can decrypt
26
-
-**PKP Signing** - Generate signatures and sign transactions using your PKP wallet
27
-
-**Lit Actions** - Execute serverless JavaScript functions for decentralized computation
29
+
-[Encryption/Decryption](/sdk/auth-context-consumption/encrypt-and-decrypt) - Encrypt data that only authorized users or conditions can decrypt.
30
+
-[PKP Signing](/sdk/auth-context-consumption/pkp-sign) - Generate signatures and sign transactions using your PKP wallet.
31
+
-[Lit Actions](/sdk/auth-context-consumption/execute-js) - Execute serverless JavaScript functions for decentralized computation.
28
32
29
33
Similar to how you pay AWS for cloud computing, this system ensures the decentralized network can sustain itself and compensate node operators. The Payment Manager allows you to deposit funds, request withdrawals (with security delays), and manage balances for yourself or delegate payment for other users - enabling applications to sponsor their users' costs for a seamless experience.
30
34
@@ -38,11 +42,12 @@ Similar to how you pay AWS for cloud computing, this system ensures the decentra
Define spending limits for the users you want to sponsor (values are in wei).
111
+
112
+
<CodeGroup>
113
+
114
+
```typescript
115
+
awaitpaymentManager.setRestriction({
116
+
totalMaxPrice: '1000000000000000000', // 1 ETH equivalent limit
117
+
requestsPerPeriod: '100', // max number of sponsored requests in a period
118
+
periodSeconds: '3600', // rolling window (1 hour in this example)
119
+
});
120
+
```
121
+
122
+
</CodeGroup>
123
+
124
+
</Step>
125
+
126
+
<Steptitle="Delegate users">
127
+
128
+
With restrictions set, delegate one or more users to spend from your payer wallet.
129
+
130
+
<CodeGroup>
131
+
132
+
```typescript
133
+
awaitpaymentManager.delegatePaymentsBatch({
134
+
userAddresses: ['0xAlice...', '0xBob...'],
135
+
});
136
+
```
137
+
138
+
</CodeGroup>
139
+
140
+
</Step>
141
+
142
+
<Steptitle="Remove users (optional)">
143
+
144
+
Undelegate users when you no longer want to sponsor them.
145
+
146
+
<CodeGroup>
147
+
148
+
```typescript
149
+
awaitpaymentManager.undelegatePaymentsBatch({
150
+
userAddresses: ['0xAlice...'],
151
+
});
152
+
```
153
+
154
+
</CodeGroup>
155
+
156
+
</Step>
157
+
</Steps>
158
+
159
+
## **Alternatively**
160
+
161
+
Manage delegation via the hosted or self-hosted Auth Service (see [Auth Services setup](/sdk/getting-started/auth-services) for the full flow).
162
+
163
+
## After Payment Delegation
164
+
165
+
**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.
166
+
167
+
<Note>
168
+
ℹ️ `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. Full request/response details live in the [Auth Services setup guide](/sdk/getting-started/auth-services#payment-delegation-apis). In practice you will:
console.log('Delegation submitted with tx hash:', delegateResponse.txHash);
138
232
139
233
// 5. Continue to use the same payer secret for future delegation calls
140
-
````
234
+
```
141
235
142
236
### How the Auth Service derives payer wallets
143
237
144
-
- The service holds a single root mnemonic (`LIT_DELEGATION_ROOT_MNEMONIC`).
145
-
- `/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.
146
-
- 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.
147
-
- 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.
148
-
- 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.
- 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