🚀 Version packages#1938
Conversation
PR SummaryHigh Risk Overview The release bundles major updates to Also shipped: Reviewed by Cursor Bugbot for commit 7583c90. Bugbot is set up for automated code reviews on this repo. Configure here. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
Auto-approved: This PR from layerzero-bot only contains package.json, lockfile, changeset, or CHANGELOG updates. |
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
layerzero-bot
force-pushed
the
changeset-release/main
branch
from
b69c2c7 to
7583c90
Compare
|
Auto-approved: This PR from layerzero-bot only contains package.json, lockfile, changeset, or CHANGELOG updates. |
4 participants
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
@layerzerolabs/devtools-move@2.0.0
Major Changes
Patch Changes
requiredDVNsinbuildConfigwith a clear error.requiredDVNsis nowoptional on the shared
Uln302UlnUserConfigtype, but this encoder maps an empty required setto the NIL sentinel (pin "no required DVNs") and cannot express "inherit the on-chain default".
Defaulting an omitted value to
[]would silently pin the least-secure shape, so it now throwsinstead — callers must pass the required DVNs explicitly, or
[]to pin "no required DVNs".@layerzerolabs/protocol-devtools@4.0.0
Major Changes
6afd57b: Treat explicitly-empty ULN302 config values as NIL sentinels instead of defaults
This lets a team pin a literal "none"/"zero" so their security configuration is exactly
what their config file says, rather than silently inheriting a default that LayerZero
controls. Being able to opt out of defaults is the point: a pinned config cannot change
underneath a team when a default is updated.
When serializing an OApp ULN302 / Read config,
requiredDVNsandoptionalDVNsnowbehave identically — omitted, explicitly-empty, and concrete each map to a distinct
on-chain meaning:
undefined) inherits the on-chain default.[]) pins "no DVNs" viaNIL_DVN_COUNT(0xff).confirmations: 0nnow serializes toNIL_CONFIRMATIONS(
type(uint64).max), while omitting it inherits the default.To make
requiredDVNsexpress "inherit" the same wayoptionalDVNsalready could, itis now OPTIONAL on
Uln302UlnUserConfigandUlnReadUlnUserConfig(previouslymandatory). This removes the need for any count override — the count is always derived
from the array, so the three serializers (EVM ULN302, EVM Read, Solana ULN302) share a
single
resolveDVNCounthelper.The read types
Uln302UlnConfig/UlnReadUlnConfigcarryoptionalDVNCount(andUlnReadUlnConfigalsorequiredDVNCount) so the stored sentinel round-trips throughthe configuration diff, and the on-chain read path normalizes rather than re-applying
the empty→NIL mapping, keeping
hasAppUlnConfigidempotent on both paths. Thelibrary-wide DEFAULT config continues to serialize literal values (it rejects NIL
sentinels on-chain). On Solana,
confirmationsis now encoded as aBNso theu64NIL sentinel survives without precision loss.
MIGRATION:
confirmations: 0,requiredDVNs: [], oroptionalDVNs: []expectingthe config to inherit the protocol default, OMIT the field instead. An explicit empty
value now pins literal zero/none — for
confirmationsthis means zero blockconfirmations, and for
requiredDVNsit means no required DVNs, bothsecurity-relevant. Re-wiring an existing OApp whose config used these empty values
will emit a
setConfigthat flips it from inherit to pinned.Uln302UlnConfig(gainsoptionalDVNCount) andUlnReadUlnConfig(gains
requiredDVNCountandoptionalDVNCount) have new required fields. Any codethat hand-constructs one of these (e.g. mocking an SDK read) must supply the new
fields.
requiredDVNsis no longer required on the user config. Code that always set itkeeps working unchanged; you may now omit it to inherit the on-chain default.
@layerzerolabs/protocol-devtools-evm@6.0.0
Major Changes
6afd57b: Treat explicitly-empty ULN302 config values as NIL sentinels instead of defaults
This lets a team pin a literal "none"/"zero" so their security configuration is exactly
what their config file says, rather than silently inheriting a default that LayerZero
controls. Being able to opt out of defaults is the point: a pinned config cannot change
underneath a team when a default is updated.
When serializing an OApp ULN302 / Read config,
requiredDVNsandoptionalDVNsnowbehave identically — omitted, explicitly-empty, and concrete each map to a distinct
on-chain meaning:
undefined) inherits the on-chain default.[]) pins "no DVNs" viaNIL_DVN_COUNT(0xff).confirmations: 0nnow serializes toNIL_CONFIRMATIONS(
type(uint64).max), while omitting it inherits the default.To make
requiredDVNsexpress "inherit" the same wayoptionalDVNsalready could, itis now OPTIONAL on
Uln302UlnUserConfigandUlnReadUlnUserConfig(previouslymandatory). This removes the need for any count override — the count is always derived
from the array, so the three serializers (EVM ULN302, EVM Read, Solana ULN302) share a
single
resolveDVNCounthelper.The read types
Uln302UlnConfig/UlnReadUlnConfigcarryoptionalDVNCount(andUlnReadUlnConfigalsorequiredDVNCount) so the stored sentinel round-trips throughthe configuration diff, and the on-chain read path normalizes rather than re-applying
the empty→NIL mapping, keeping
hasAppUlnConfigidempotent on both paths. Thelibrary-wide DEFAULT config continues to serialize literal values (it rejects NIL
sentinels on-chain). On Solana,
confirmationsis now encoded as aBNso theu64NIL sentinel survives without precision loss.
MIGRATION:
confirmations: 0,requiredDVNs: [], oroptionalDVNs: []expectingthe config to inherit the protocol default, OMIT the field instead. An explicit empty
value now pins literal zero/none — for
confirmationsthis means zero blockconfirmations, and for
requiredDVNsit means no required DVNs, bothsecurity-relevant. Re-wiring an existing OApp whose config used these empty values
will emit a
setConfigthat flips it from inherit to pinned.Uln302UlnConfig(gainsoptionalDVNCount) andUlnReadUlnConfig(gains
requiredDVNCountandoptionalDVNCount) have new required fields. Any codethat hand-constructs one of these (e.g. mocking an SDK read) must supply the new
fields.
requiredDVNsis no longer required on the user config. Code that always set itkeeps working unchanged; you may now omit it to inherit the on-chain default.
Patch Changes
@layerzerolabs/protocol-devtools-solana@9.0.0
Major Changes
6afd57b: Treat explicitly-empty ULN302 config values as NIL sentinels instead of defaults
This lets a team pin a literal "none"/"zero" so their security configuration is exactly
what their config file says, rather than silently inheriting a default that LayerZero
controls. Being able to opt out of defaults is the point: a pinned config cannot change
underneath a team when a default is updated.
When serializing an OApp ULN302 / Read config,
requiredDVNsandoptionalDVNsnowbehave identically — omitted, explicitly-empty, and concrete each map to a distinct
on-chain meaning:
undefined) inherits the on-chain default.[]) pins "no DVNs" viaNIL_DVN_COUNT(0xff).confirmations: 0nnow serializes toNIL_CONFIRMATIONS(
type(uint64).max), while omitting it inherits the default.To make
requiredDVNsexpress "inherit" the same wayoptionalDVNsalready could, itis now OPTIONAL on
Uln302UlnUserConfigandUlnReadUlnUserConfig(previouslymandatory). This removes the need for any count override — the count is always derived
from the array, so the three serializers (EVM ULN302, EVM Read, Solana ULN302) share a
single
resolveDVNCounthelper.The read types
Uln302UlnConfig/UlnReadUlnConfigcarryoptionalDVNCount(andUlnReadUlnConfigalsorequiredDVNCount) so the stored sentinel round-trips throughthe configuration diff, and the on-chain read path normalizes rather than re-applying
the empty→NIL mapping, keeping
hasAppUlnConfigidempotent on both paths. Thelibrary-wide DEFAULT config continues to serialize literal values (it rejects NIL
sentinels on-chain). On Solana,
confirmationsis now encoded as aBNso theu64NIL sentinel survives without precision loss.
MIGRATION:
confirmations: 0,requiredDVNs: [], oroptionalDVNs: []expectingthe config to inherit the protocol default, OMIT the field instead. An explicit empty
value now pins literal zero/none — for
confirmationsthis means zero blockconfirmations, and for
requiredDVNsit means no required DVNs, bothsecurity-relevant. Re-wiring an existing OApp whose config used these empty values
will emit a
setConfigthat flips it from inherit to pinned.Uln302UlnConfig(gainsoptionalDVNCount) andUlnReadUlnConfig(gains
requiredDVNCountandoptionalDVNCount) have new required fields. Any codethat hand-constructs one of these (e.g. mocking an SDK read) must supply the new
fields.
requiredDVNsis no longer required on the user config. Code that always set itkeeps working unchanged; you may now omit it to inherit the on-chain default.
Patch Changes
@layerzerolabs/devtools-solana@3.1.0
Minor Changes
bigIntToBNhelper (andBignumtype) for converting abigintto theBNtypethe Solana program instruction builders expect, preserving full precision for
u64values that overflow a JS number.
@layerzerolabs/metadata-tools@4.0.0
Minor Changes
6afd57b:
generateConnectionsConfignow treats a pathway with no optional DVNs as an explicit"no optional DVNs" (pinned via the NIL sentinel) instead of a value that inherits the
on-chain default.
The emitted config still carries
optionalDVNs: [], but under the new ULN302 sentinelsemantics that empty array now pins "no optional DVNs" on-chain rather than falling back
to the chain default. This is deliberate: the metadata config is the primary way a config
is consumed, and an empty optional-DVN set should be visible in the file rather than
silently inheriting the default.
Re-wiring a pathway that previously inherited the on-chain default will now pin its
optional-DVN set explicitly. If that default carried optional DVNs (a non-zero threshold),
pinning an empty set drops them — this is intended. The goal is that a team's verification
config is exactly what their config file says, not something that can change underneath them
when a LayerZero-controlled default is updated. An empty optional-DVN set means "no optional
DVNs"; teams that want an optional quorum should list those DVNs explicitly. Required DVNs
are unaffected by this change.
Patch Changes
@layerzerolabs/omnicounter-devtools@6.0.0
Patch Changes
@layerzerolabs/omnicounter-devtools-evm@8.0.0
Patch Changes
@layerzerolabs/toolbox-hardhat@0.6.14
Patch Changes
@layerzerolabs/ua-devtools@6.0.0
Patch Changes
@layerzerolabs/ua-devtools-evm@8.0.0
Patch Changes
@layerzerolabs/ua-devtools-evm-hardhat@10.0.0
Patch Changes
round-trip the new NIL-sentinel semantics: a field inheriting the on-chain default is
OMITTED (for both
requiredDVNsandoptionalDVNs, which now behave identically) ratherthan emitted as an explicit empty value that would pin zero/none on re-apply. Pinned-none
configs continue to emit
[]/0n.@layerzerolabs/ua-devtools-solana@9.0.0
Patch Changes
@layerzerolabs/verify-contract@1.5.2
Patch Changes
@layerzerolabs/lzapp-migration-example@0.3.10
Patch Changes
@layerzerolabs/oft-adapter-initia-example@0.1.4
Patch Changes
@layerzerolabs/oft-initia-example@0.0.11
Patch Changes
@layerzerolabs/test-setup-devtools-evm-hardhat@10.0.0
Patch Changes