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/lit-client](#lit-client)|[8.1.0](https://www.npmjs.com/package/%40lit-protocol%2Flit-client)| Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually. |
10
+
|[@lit-protocol/auth](#auth)|[8.1.0](https://www.npmjs.com/package/%40lit-protocol%2Fauth)| Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually. |
11
+
|[@lit-protocol/networks](#networks)|[8.1.0](https://www.npmjs.com/package/%40lit-protocol%2Fnetworks)| Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually. |
|[@lit-protocol/auth-helpers](#auth-helpers)|[8.1.0](https://www.npmjs.com/package/%40lit-protocol%2Fauth-helpers)| Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually. |
|[@lit-protocol/contracts](#contracts)|[0.6.0](https://www.npmjs.com/package/%40lit-protocol%2Fcontracts)| Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually. |
rss={{ title: "lit-client", description: "No release notes provided yet." }}
30
+
description="v8.1.0"
31
+
tags={["Minor Changes"]}
32
+
rss={{ title: "lit-client", description: "Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually." }}
30
33
id="lit-client"
31
34
>
32
35
33
-
No release notes available.
36
+
## Minor Changes
37
+
38
+
- Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually.
34
39
</Update>
35
40
36
41
<Update
37
42
label="auth"
38
-
description="v8.0.2"
39
-
tags={["Release"]}
40
-
rss={{ title: "auth", description: "No release notes provided yet." }}
43
+
description="v8.1.0"
44
+
tags={["Minor Changes", "Patch Changes"]}
45
+
rss={{ title: "auth", description: "Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually." }}
41
46
id="auth"
42
47
>
43
48
44
-
No release notes available.
49
+
## Minor Changes
50
+
51
+
- Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually.
52
+
53
+
## Patch Changes
54
+
55
+
- Allows `WalletClientAuthenticator.authenticate` to build SIWE messages with user-specified fields (`domain`, `uri`, `statement`, etc.) while still managing the nonce internally.
rss={{ title: "networks", description: "Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually." }}
52
63
id="networks"
53
64
>
54
65
66
+
## Minor Changes
67
+
68
+
- Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually.
rss={{ title: "auth-helpers", description: "No release notes provided yet." }}
127
+
description="v8.1.0"
128
+
tags={["Minor Changes"]}
129
+
rss={{ title: "auth-helpers", description: "Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually." }}
88
130
id="auth-helpers"
89
131
>
90
132
91
-
No release notes available.
133
+
## Minor Changes
134
+
135
+
- Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually.
rss={{ title: "contracts", description: "Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually." }}
113
157
id="contracts"
114
158
>
115
159
116
-
## Patch Changes
160
+
## Minor Changes
117
161
118
-
-release `naga-test` network support
162
+
-Converted viem from a bundled dependency to a peer dependency to avoid build errors from version conflicts (e.g., missing exports like sendCallsSync) and improve compatibility by reducing dependency lock-in. Consumers must now install compatible versions manually.
description: 'Common questions about using the Lit JS SDK'
4
+
---
5
+
6
+
# Frequently Asked Questions
7
+
8
+
## What's the default `responseStrategy` for `executeJs` in v8?
9
+
10
+
The behavior matches v7. When you omit `responseStrategy`, the SDK calls `processLitActionResponseStrategy` with `{ strategy: 'leastCommon' }`. If you provide an unrecognized value, the helper still falls back to `leastCommon`.
11
+
12
+
This default keeps compatibility with `Lit.Actions.runOnce`. Only the node that runs the `runOnce` block returns a value, so selecting the least-common response ensures that single result is preserved. When `runOnce` is not used, all nodes should emit the same payload, making least- vs most-common equivalent—the former stayed in place because it was the quickest path to enabling the new `runOnce` flow in v8.
The system by which funds and resources are allocated to the wider Lit Protocol ecosystem is actively being worked out. LIP-001 proposes to handle this via a new token model, veLITKEY, which would give LITKEY stakers the power to govern token emissions and where funds are allocated.
37
+
38
+
[Review the proposal](https://litprotocol.discourse.group/t/lip-001-velitkey-a-token-model-for-sovereign-economic-development/14).
39
+
34
40
## Node Operations
35
41
36
42
Lit remains a federated network at this stage. This means that the set of node operators responsible for performing threshold cryptographic operations is curated, but members of the community can openly participate pending they meet the hardware and staking requirements.
Copy file name to clipboardExpand all lines: docs/governance/lit-improvement-proposals.mdx
+8-11Lines changed: 8 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,24 +2,21 @@
2
2
title: "Lit Improvement Proposals (LIPs)"
3
3
---
4
4
5
-
Lit Improvement Proposals (LIPs) are used to propose new features and upgrades to the core Lit Protocol architecture (including smart contracts) and surrounding ecosystem. LIPs are organized into three categories based on their specific content and area of focus. As covered in the sections above, these categories include protocol level improvements, treasury allocation, and governance improvement proposals. LIPs are used to publicly and transparently track protocol upgrades, new features, and growth initiatives through a standardized template and workflow.
5
+
Lit Improvement Proposals (LIPs) are used to propose new features and upgrades to the core Lit Protocol architecture (including smart contracts) and surrounding ecosystem. LIPs are organized into three categories based on their specific content and area of focus. As covered in the sections above, these categories include protocol level improvements, resource allocation, and governance improvement proposals. LIPs are used to publicly and transparently track protocol upgrades, new features, and growth initiatives through a standardized template and workflow.
6
6
7
7
All LIPs go through the LIP process (documented below) before being passed off to the Protocol Council for final review and approval. If approved, the proposal is then passed off to the relevant parties for execution / implementation.
8
8
9
9
## LIP Process
10
10
11
-
All LIPs are initially submitted and discussed in the relevant category of the Lit governance forum. After a given proposal has moved past the “idea” stage, it must be submitted as a pull request to the LIP repo on GitHub.
11
+
All LIPs are initially submitted and discussed in the relevant category of the Lit governance forum. After a given proposal has moved past the initial ideation stage, it must be submitted as a pull request to the LIP repo on GitHub.
12
12
13
13
All LIPs are tagged on the Lit governance forum and associated GitHub repo based on the specific stage they are in:
14
14
15
-
- “Idea”: initial proposal ideas are submitted to the governance forum for discussion and refinement.
16
-
- “Draft”: after a proposal has moved past the “idea” stage, it is submitted to the LIP repo as an official draft proposal. The template can be found here.
17
-
- “Review”: after a draft proposal has been submitted, it is reviewed by the relevant parties which vary according to the context of the proposal itself.
18
-
- “Vote”: proposals that move to the “vote” stage are passed off to the Protocol Council for final review and approval.
19
-
- “Accepted”: proposals that have been reviewed and accepted by the Protocol Council.
20
-
- “Implementing”: proposals that are actively being implemented.
21
-
- “Completed”: proposals that have been accepted and implemented.
15
+
- “Draft”: initial proposals are to be submitted to the [governance forum](https://litprotocol.discourse.group/) for discussion and refinement. After a proposal has moved past the initial draft stage, it is submitted to the [LIP repo](https://github.com/LIT-Protocol/Lit-Improvement-Proposals) for review.
16
+
- “Review”: after a draft proposal has been submitted, it is reviewed by the relevant parties which vary according to the context of the proposal itself.
17
+
- “Accepted”: proposals that have been reviewed and accepted by the Protocol Council and are in active implementation.
22
18
- “Rejected”: proposals that have been rejected by the Protocol Council.
19
+
- “Completed”: proposals that have been accepted, implemented, and merged.
23
20
- “Closed”: proposals that have been closed.
24
21
25
22
## Lit Protocol Council Review Process
@@ -30,8 +27,8 @@ After a given LIP has been reviewed, the Protocol Council will report their deci
30
27
31
28
## Submitting LIPs
32
29
33
-
At this time, the Lit Protocol development company will be the primary party tasked with creating and submitting new LIPs. However, anyone can suggest improvements or changes by starting a discussion on the Lit governance forum using the applicable “idea” tag. All suggestions will be reviewed and prioritized according to current protocol objectives and available resources.
30
+
At this time, the Lit Protocol development company will be the primary party tasked with creating and submitting new LIPs. However, anyone can suggest improvements or changes by starting a discussion on the Lit [governance forum](https://litprotocol.discourse.group/). All suggestions will be reviewed and prioritized according to current protocol objectives and available resources.
34
31
35
-
As discussed in the sections above, the Protocol Council will be the core body tasked with reviewing and approving or rejecting all LIPs at this time. Once Lit Protocol and its associated governance processes have reached a greater level of maturity and stability, the Protocol Council may be dissolved entirely with governance decision making being passed off to relevant ecosystem stakeholders and working groups.
32
+
The Protocol Council—in coordination with the Lit Association—will be the core body tasked with reviewing and approving or rejecting all LIPs at this time. Once Lit Protocol and its associated governance processes have reached a greater level of maturity and stability, the Protocol Council may be dissolved entirely with governance decision making being passed off to relevant ecosystem stakeholders and working groups.
0 commit comments