Releases: Agoric/agoric-sdk
agoric-upgrade-18-rc3
The Agoric OpCo engineering team is pleased to publish the agoric-upgrade-18-rc3 release. This release is primarily intended to deploy governance/network upgrades and provide validator node memory improvements.
The following new features are included in this release:
-
#10258, #10133, #10134 and more: enable EC membership changes and change EC slate from 6 to 3 members
-
#9716 and more: MN Sustainability
-
#8400, #10020, #9595 and more: Oracle price improvements (reduces memory and diskspace growth for new price feeds)
The release contains at least the following fixes:
-
#10292: Fixes a case with AmountMath.isGTE involving invitations with common descriptions but distinct instance handles
-
#4103: Make xsnap exit quietly upon command pipe EOF
-
#9039: Change processUpgradeVat to delete c-list entries
-
#10455: add missing slog type
-
#10454: remove addInstance call from add-auction.js
-
#10534: bump cosmossdk.io/math to v1.4.0
-
#10551: [new since rc2] fixes event name typo in telemetry
-
#10635: [new since rc2] fixes empty context persisting when remaining beans are negative after run finish
-
#10615: [new since rc2] don't reschedule auction's price notifier if we already have one (issue details)
-
#10634: [new since rc2] add dATOM brand name to DEVNET config
The full set of changes in this release can be found at #10382, #10527, #10548 and #10656, and reviewed in detail as agoric-upgrade-17...agoric-upgrade-18-rc3.
Assuming this release satisfies all pre-release/testnet validation checks, it will be promoted to agoric-upgrade-18, and recommended for chains to upgrade from the previous agoric-upgrade-17 release. As a chain-halting upgrade, once approved, all chain validators will need to upgrade from agoric-upgrade-17 to this new version (after the chain halts due to reaching the height required in a governance proposal).
State-sync
State-sync snapshots now only include minimal data to restore a node. However there are still continued performance issues related to state-sync. In particular, we've observed that on some deployments, the snapshot taking and restoring process can take multiple hours, require about 20GB of temporary free disk space, and 16GB of memory.
Cosmos Upgrade Handler Name
Below is the cosmos upgrade handler name for this release. This is the name that can be used in governance proposals to deploy this upgrade.
for emerynet
Cosmos Upgrade Handler Name: agoric-upgrade-18-emerynet-rc3
for devnet
Cosmos Upgrade Handler Name: agoric-upgrade-18-devnet
for mainnet
Cosmos Upgrade Handler Name: agoric-upgrade-18-mainnet
Tags
Below is the git information related to this software release. Note the git tag does not always match the cosmos upgrade handler name.
Git Tag: agoric-upgrade-18-rc3
Git Commit: 793783b3b1ff6b47565a959cb7ba60a1835e2486
@agoric/cosmos package version: 0.35.0-u18.3
Docker: ghcr.io/agoric/agoric-sdk:53
As shown in go.mod this release is based on:
ibc-go v6.3.1
cosmos-sdk v0.46.16
cometbft v0.34.30
How to upgrade
Presuming that your node is running agoric-upgrade-17, once the upgrade height for a subsequent proposal to upgrade to agoric-upgrade-18-rc3 has been reached, your node will halt automatically allowing you to upgrade the agoric stack.
Prerequisites
Install supported versions of Go, Node.js, and a compiler such as gcc or clang as documented in the README.
Make sure that the environment running the agd service has the same Node.js version as the environment used for building. In particular, if using nvm to manage Node.js version, the service environment should enable nvm and use the same version.
Building
# (stop the agd service)
cd agoric-sdk
git fetch --all
git checkout agoric-upgrade-18-rc3
git clean -xdf && git submodule foreach --recursive git clean -xdf
./bin/agd build
# (start the agd service)
Do not copy the agd script or Go binary to another location. If you would like to have an executable agd in another location, then create a symlink in that location pointing to agoric-sdk/bin/agd.
Troubleshooting module ... was compiled against a different Node.js version and SyntaxError issues
The agd service is not using the same version of Node.js as the one used when building. The most likely cause is that nvm was used to manage the Node.js version in the shell when building. Either install the required version of Node.js globally using the system's package manager, or enable nvm in the environment of the agd service.
Troubleshooting repoconfig.sh: No such file or directory
Unlike typical cosmos-sdk chains where the daemon is a single executable file, Agoric's use of cosmos-sdk depends on many components of agoric-sdk at runtime. Copying agd to /usr/local/bin or the like is unlikely to produce a working installation. For more detail, see: #7825
Troubleshooting Cannot find dependency ... in systemd
If you have LimitNOFILE=4096 in your systemd unit file, change it to LimitNOFILE=65536. For more detail, see #7817
Specifying --upgrade-info for the software upgrade proposal
The ./scripts/gen-upgrade-proposal.sh is designed to aid in composing a agd tx submit-proposal software-upgrade ... command. In particular, it captures package checksums to verify integrity of downloaded software.
agoric-upgrade-18-rc2
The Agoric OpCo engineering team is pleased to publish the agoric-upgrade-18-rc2 release. This release is primarily intended to deploy governance/network upgrades and provide validator node memory improvements.
The following new features are included in this release:
-
#10258, #10133, #10134 and more: enable EC membership changes and change EC slate from 6 to 3 members
-
#9716 and more: MN Sustainability
-
#8400, #10020, #9595 and more: Oracle price improvements (reduces memory and diskspace growth for new price feeds)
The release contains at least the following fixes:
-
#10292: Fixes a case with AmountMath.isGTE involving invitations with common descriptions but distinct instance handles
-
#4103: Make xsnap exit quietly upon command pipe EOF
-
#9039: Change processUpgradeVat to delete c-list entries
-
#10455: add missing slog type
-
#10454: remove addInstance call from add-auction.js
-
#10534: [new since rc1] bump cosmossdk.io/math to v1.4.0
The full set of changes in this release can be found at #10382, #10527 and #10548, and reviewed in detail as agoric-upgrade-17...agoric-upgrade-18-rc2.
Assuming this release satisfies all pre-release/testnet validation checks, it will be promoted to agoric-upgrade-18, and recommended for chains to upgrade from the previous agoric-upgrade-17 release. As a chain-halting upgrade, once approved, all chain validators will need to upgrade from agoric-upgrade-17 to this new version (after the chain halts due to reaching the height required in a governance proposal).
State-sync
State-sync snapshots now only include minimal data to restore a node. However there are still continued performance issues related to state-sync. In particular, we've observed that on some deployments, the snapshot taking and restoring process can take multiple hours, require about 20GB of temporary free disk space, and 16GB of memory.
Cosmos Upgrade Handler Name
Below is the cosmos upgrade handler name for this release. This is the name that can be used in governance proposals to deploy this upgrade.
for emerynet
Cosmos Upgrade Handler Name: agoric-upgrade-18-basic-2
for devnet
Cosmos Upgrade Handler Name: agoric-upgrade-18-devnet
for mainnet
Cosmos Upgrade Handler Name: agoric-upgrade-18-mainnet
Tags
Below is the git information related to this software release. Note the git tag does not always match the cosmos upgrade handler name.
Git Tag: agoric-upgrade-18-rc2
Git Commit: 431b36a49f8574ce49c29d152bf0ace03eb5a348
@agoric/cosmos package version: 0.35.0-u18.2
Docker: ghcr.io/agoric/agoric-sdk:52
As shown in go.mod this release is based on:
ibc-go v6.3.1
cosmos-sdk v0.46.16
cometbft v0.34.30
How to upgrade
Presuming that your node is running agoric-upgrade-17, once the upgrade height for a subsequent proposal to upgrade to agoric-upgrade-18-rc2 has been reached, your node will halt automatically allowing you to upgrade the agoric stack.
Prerequisites
Install supported versions of Go, Node.js, and a compiler such as gcc or clang as documented in the README.
Make sure that the environment running the agd service has the same Node.js version as the environment used for building. In particular, if using nvm to manage Node.js version, the service environment should enable nvm and use the same version.
Building
# (stop the agd service)
cd agoric-sdk
git fetch --all
git checkout agoric-upgrade-18-rc2
git clean -xdf && git submodule foreach --recursive git clean -xdf
./bin/agd build
# (start the agd service)
Do not copy the agd script or Go binary to another location. If you would like to have an executable agd in another location, then create a symlink in that location pointing to agoric-sdk/bin/agd.
Troubleshooting module ... was compiled against a different Node.js version and SyntaxError issues
The agd service is not using the same version of Node.js as the one used when building. The most likely cause is that nvm was used to manage the Node.js version in the shell when building. Either install the required version of Node.js globally using the system's package manager, or enable nvm in the environment of the agd service.
Troubleshooting repoconfig.sh: No such file or directory
Unlike typical cosmos-sdk chains where the daemon is a single executable file, Agoric's use of cosmos-sdk depends on many components of agoric-sdk at runtime. Copying agd to /usr/local/bin or the like is unlikely to produce a working installation. For more detail, see: #7825
Troubleshooting Cannot find dependency ... in systemd
If you have LimitNOFILE=4096 in your systemd unit file, change it to LimitNOFILE=65536. For more detail, see #7817
Specifying --upgrade-info for the software upgrade proposal
The ./scripts/gen-upgrade-proposal.sh is designed to aid in composing a agd tx submit-proposal software-upgrade ... command. In particular, it captures package checksums to verify integrity of downloaded software.
agoric-upgrade-18-rc1
The Agoric OpCo engineering team is pleased to publish the agoric-upgrade-18-rc1 release. This release is primarily intended to deploy governance/network upgrades and provide validator node memory improvements
The following new features are included in this release:
-
#10258, #10133, #10134 and more: enable EC membership changes and change EC slate from 6 to 3 members
-
#9716 and more: MN Sustainability
-
#8400, #10020, #9595 and more: Oracle price improvements (reduces memory and diskspace growth for new price feeds)
The release contains at least the following fixes:
-
#10292: Fixes a case with AmountMath.isGTE involving invitations with common descriptions but distinct instance handles
-
#4103: Make xsnap exit quietly upon command pipe EOF
-
#9039: Change processUpgradeVat to delete c-list entries
-
#10455: [new since rc0] add missing slog type
-
#10454: [new since rc0] remove addInstance call from add-auction.js
The full set of changes in this release can be found at #10382 and #10527, and reviewed in detail as agoric-upgrade-17...agoric-upgrade-18-rc1.
Assuming this release satisfies all pre-release/testnet validation checks, it will be promoted to agoric-upgrade-18, and recommended for chains to upgrade from the previous agoric-upgrade-17 release. As a chain-halting upgrade, once approved, all chain validators will need to upgrade from agoric-upgrade-17 to this new version (after the chain halts due to reaching the height required in a governance proposal).
State-sync
State-sync snapshots now only include minimal data to restore a node. However there are still continued performance issues related to state-sync. In particular, we've observed that on some deployments, the snapshot taking and restoring process can take multiple hours, require about 20GB of temporary free disk space, and 16GB of memory.
Cosmos Upgrade Handler Name
Below is the cosmos upgrade handler name for this release. This is the name that can be used in governance proposals to deploy this upgrade.
for emerynet
Cosmos Upgrade Handler Name: agoric-upgrade-18-basic-2
for devnet
Cosmos Upgrade Handler Name: agoric-upgrade-18-devnet
for mainnet
Cosmos Upgrade Handler Name: agoric-upgrade-18-mainnet
Tags
Below is the git information related to this software release. Note the git tag does not always match the cosmos upgrade handler name.
Git Tag: agoric-upgrade-18-rc1
Git Commit: 329d378c894020c788ed45918bf26105edfdf969
@agoric/cosmos package version: 0.35.0-u18.1
Docker: ghcr.io/agoric/agoric-sdk:51
As shown in go.mod this release is based on:
ibc-go v6.3.1
cosmos-sdk v0.46.16
cometbft v0.34.30
How to upgrade
Presuming that your node is running agoric-upgrade-17, once the upgrade height for a subsequent proposal to upgrade to agoric-upgrade-18-rc1 has been reached, your node will halt automatically allowing you to upgrade the agoric stack.
Prerequisites
Install supported versions of Go, Node.js, and a compiler such as gcc or clang as documented in the README.
Make sure that the environment running the agd service has the same Node.js version as the environment used for building. In particular, if using nvm to manage Node.js version, the service environment should enable nvm and use the same version.
Building
# (stop the agd service)
cd agoric-sdk
git fetch --all
git checkout agoric-upgrade-18-rc1
git clean -xdf && git submodule foreach --recursive git clean -xdf
./bin/agd build
# (start the agd service)
Do not copy the agd script or Go binary to another location. If you would like to have an executable agd in another location, then create a symlink in that location pointing to agoric-sdk/bin/agd.
Troubleshooting module ... was compiled against a different Node.js version and SyntaxError issues
The agd service is not using the same version of Node.js as the one used when building. The most likely cause is that nvm was used to manage the Node.js version in the shell when building. Either install the required version of Node.js globally using the system's package manager, or enable nvm in the environment of the agd service.
Troubleshooting repoconfig.sh: No such file or directory
Unlike typical cosmos-sdk chains where the daemon is a single executable file, Agoric's use of cosmos-sdk depends on many components of agoric-sdk at runtime. Copying agd to /usr/local/bin or the like is unlikely to produce a working installation. For more detail, see: #7825
Troubleshooting Cannot find dependency ... in systemd
If you have LimitNOFILE=4096 in your systemd unit file, change it to LimitNOFILE=65536. For more detail, see #7817
Specifying --upgrade-info for the software upgrade proposal
The ./scripts/gen-upgrade-proposal.sh is designed to aid in composing a agd tx submit-proposal software-upgrade ... command. In particular, it captures package checksums to verify integrity of downloaded software.
agoric-upgrade-18-rc0
The Agoric OpCo engineering team is pleased to publish the agoric-upgrade-18-rc0 release. This release is primarily intended to deploy governance/network upgrades and provide validator node memory improvements.
The following new features are included in this release:
-
#10258, #10133, #10134 and more: enable EC membership changes and change EC slate from 6 to 3 members
-
#9716 and more: MN Sustainability
-
#8400, #10020, #9595 and more: Oracle price improvements (reduces memory and diskspace growth for new price feeds)
The release contains at least the following fixes:
-
#10292: Fixes a case with AmountMath.isGTE involving invitations with common descriptions but distinct instance handles
-
#4103: Make xsnap exit quietly upon command pipe EOF
-
#9039: Change processUpgradeVat to delete c-list entries
The full set of changes in this release can be found at #10382 and reviewed in details as agoric-upgrade-17...agoric-upgrade-18-rc0.
Assuming this release satisfies all pre-release/testnet validation checks, it will be promoted to agoric-upgrade-18, and recommended for chains to upgrade from the previous agoric-upgrade-17 release. As a chain-halting upgrade, once approved, all chain validators will need to upgrade from agoric-upgrade-17 to this new version (after the chain halts due to reaching the height required in a governance proposal).
State-sync
State-sync snapshots now only include minimal data to restore a node. However there are still continued performance issues related to state-sync. In particular, we've observed that on some deployments, the snapshot taking and restoring process can take multiple hours, require about 20GB of temporary free disk space, and 16GB of memory.
Cosmos Upgrade Handler Name
Below is the cosmos upgrade handler names for this release. This is the name that can be used in governance proposals to deploy this upgrade.
for emerynet
Cosmos Upgrade Handler Name: agoric-upgrade-18-emerynet
for devnet
Cosmos Upgrade Handler Name: agoric-upgrade-18-devnet
for mainnet
Cosmos Upgrade Handler Name: agoric-upgrade-18-mainnet
Tags
Below is the git information related to this software release. Note the git tag does not always match the cosmos upgrade handler name.
Git Tag: agoric-upgrade-18-rc0
Git Commit: c22e7250188bbdb07bc021dffdb88af0309a7aa8
@agoric/cosmos package version: 0.35.0-u18.0
Docker: ghcr.io/agoric/agoric-sdk:50
As shown in go.mod this release is based on:
ibc-go v6.3.1
cosmos-sdk v0.46.16
cometbft v0.34.30
How to upgrade
Presuming that your node is running agoric-upgrade-17, once the upgrade height for a subsequent proposal to upgrade to agoric-upgrade-18-rc0 has been reached, your node will halt automatically allowing you to upgrade the agoric stack.
Prerequisites
Install supported versions of Go, Node.js, and a compiler such as gcc or clang as documented in the README.
Make sure that the environment running the agd service has the same Node.js version as the environment used for building. In particular, if using nvm to manage Node.js version, the service environment should enable nvm and use the same version.
Building
# (stop the agd service)
cd agoric-sdk
git fetch --all
git checkout agoric-upgrade-18-rc0
git clean -xdf && git submodule foreach --recursive git clean -xdf
./bin/agd build
# (start the agd service)
Do not copy the agd script or Go binary to another location. If you would like to have an executable agd in another location, then create a symlink in that location pointing to agoric-sdk/bin/agd.
Troubleshooting module ... was compiled against a different Node.js version and SyntaxError issues
The agd service is not using the same version of Node.js as the one used when building. The most likely cause is that nvm was used to manage the Node.js version in the shell when building. Either install the required version of Node.js globally using the system's package manager, or enable nvm in the environment of the agd service.
Troubleshooting repoconfig.sh: No such file or directory
Unlike typical cosmos-sdk chains where the daemon is a single executable file, Agoric's use of cosmos-sdk depends on many components of agoric-sdk at runtime. Copying agd to /usr/local/bin or the like is unlikely to produce a working installation. For more detail, see: #7825
Troubleshooting Cannot find dependency ... in systemd
If you have LimitNOFILE=4096 in your systemd unit file, change it to LimitNOFILE=65536. For more detail, see #7817
Specifying --upgrade-info for the software upgrade proposal
The ./scripts/gen-upgrade-proposal.sh is designed to aid in composing a agd tx submit-proposal software-upgrade ... command. In particular, it captures package checksums to verify integrity of downloaded software.
agoric-upgrade-17
The Agoric OpCo engineering team is pleased to publish the agoric-upgrade-17 release. This release includes updates to Orchestration Core that advance chain orchestration facilities, and also improvements to reduce the storage and memory footprint required of validator nodes.
The following new features are included in this release:
- #9064: orchestration can create Interchain accounts (ICAs) on a host chain
- #9890: query support in orchestration flows
- #10029: orchestration account balance queries
- #10032: app.toml configuration for vat snapshot and delivery transcript JS database entry retention
- #10036: app.toml configuration for vat snapshot and delivery transcript file archiving
- #9900: reduce contract bundle size
The release contains at least the following fixes:
- #9961: Remotable/Presence garbage collection edge cases
- #10110: Remove init-chain-info proposal intended for a future release
The full set of changes in this release can be found at #10097 and #10114, and reviewed in detail as agoric-upgrade-16...agoric-upgrade-17.
This release has satisfied all pre-release/testnet validation checks, and is now recommended for chains to upgrade from the previous agoric-upgrade-16 release. As a chain-halting upgrade, once approved, all chain validators will need to upgrade from agoric-upgrade-16 to this new version (after the chain halts due to reaching the height required in a governance proposal).
New app configuration
We've added support for a [swingset] section to app.toml for customizing local consensus-independent behavior of the Swingset JavaScript VM. Of particular note are the vat snapshot and delivery transcript retention settings, which can be used to significantly reduce growth of the JS database size.
| Setting | Default value | Other values | Purpose |
|---|---|---|---|
slogfile |
<path to file> | if non-empty, where to write a "slog" (Swingset delivery log file) | |
max-vats-online |
50 | <positive integer> | maximum number of vats to keep loaded in memory |
vat-snapshot-retention |
"operational" | "debug" | "debug" to preserve all vat snapshots in the JS database; "operational" to preserve only the most recent |
vat-transcript-retention |
"default" | "archival", "operational" | "archival" to preserve all vat delivery transcript spans in the JS database; "operational" to drop those preceding the most recent vat snapshot; "default" to derive from pruning ("archival" with pruning = "nothing", otherwise "operational") |
vat-snapshot-archive-dir |
<path to directory> | if non-empty, where to write gzipped vat snapshot files | |
vat-transcript-archive-dir |
<path to directory> | if non-empty, where to write gzipped historical (closed) vat delivery transcript span files |
Any new app.toml file will be initialized with the new section, but we recommend that the following be added to existing files (and then customized per your needs):
###############################################################################
### SwingSet Configuration ###
###############################################################################
[swingset]
# The path at which a SwingSet log "slog" file should be written.
# If relative, it is interpreted against the application home directory
# (e.g., ~/.agoric).
# May be overridden by a SLOGFILE environment variable, which if relative is
# interpreted against the working directory.
slogfile = ""
# The maximum number of vats that the SwingSet kernel will bring online. A lower number
# requires less memory but may have a negative performance impact if vats need to
# be frequently paged out to remain under this limit.
max-vats-online = 50
# Retention of vat snapshots, with values analogous to those of export
# 'artifactMode' (cf.
# https://github.com/Agoric/agoric-sdk/blob/master/packages/swing-store/docs/data-export.md#optional--historical-data ).
# * "debug": keep all snapshots
# * "operational": keep only the last snapshot
vat-snapshot-retention = "operational"
# Retention of vat transcript spans, with values analogous to those of export
# 'artifactMode' (cf.
# https://github.com/Agoric/agoric-sdk/blob/master/packages/swing-store/docs/data-export.md#optional--historical-data ).
# * "archival": keep all transcript spans
# * "operational": keep only necessary transcript spans (i.e., since the
# last snapshot of their vat)
# * "default": determined by 'pruning' ("archival" if 'pruning' is "nothing",
# otherwise "operational")
vat-transcript-retention = "default"
# Archival of gzipped vat snapshots.
vat-snapshot-archive-dir = ""
# Archival of historical (i.e., closed) vat transcript spans to gzipped files.
vat-transcript-archive-dir = ""State-sync
State-sync snapshots now only include minimal data to restore a node, and the new configuration settings will help further reduce requirements of non-archival nodes. However, there may still be continued performance issues related to state-sync. In particular, we've observed that on some deployments, the snapshot taking and restoring process can take multiple hours, require about 20GB of temporary free disk space, and 16GB of memory.
Cosmos Upgrade Handler Name
Below is the cosmos upgrade handler name for this release. This is the name that can be used in governance proposals to deploy this upgrade.
Cosmos Upgrade Handler Name: agoric-upgrade-17
Tags
Below is the git information related to this software release. Note the git tag does not always match the cosmos upgrade handler name.
Git Tag: agoric-upgrade-17
Git Commit: 5259430561693bfcf58516c3ea54123895859708
@agoric/cosmos package version: 0.35.0-u17.1
Docker: ghcr.io/agoric/agoric-sdk:49
As shown in go.mod this release is based on:
ibc-go v6.3.1
cosmos-sdk v0.46.16
cometbft v0.34.30
How to upgrade
Presuming that your node is running agoric-upgrade-16, once the upgrade height for a subsequent proposal to upgrade to agoric-upgrade-17 has been reached, your node will halt automatically allowing you to upgrade the agoric stack.
Prerequisites
Install supported versions of Go, Node.js, and a compiler such as gcc or clang as documented in the README.
Make sure that the environment running the agd service has the same Node.js version as the environment used for building. In particular, if using nvm to manage Node.js version, the service environment should enable nvm and use the same version.
Building
# (stop the agd service)
cd agoric-sdk
git fetch --all
git checkout agoric-upgrade-17
git clean -xdf && git submodule foreach --recursive git clean -xdf
./bin/agd build
# (start the agd service)
Do not copy the agd script or Go binary to another location. If you would like to have an executable agd in another location, then create a symlink in that location pointing to agoric-sdk/bin/agd.
Troubleshooting module ... was compiled against a different Node.js version and SyntaxError issues
The agd service is not using the same version of Node.js as the one used when building. The most likely cause is that nvm was used to manage the Node.js version in the shell when building. Either install the required version of Node.js globally using the system's package manager, or enable nvm in the environment of the agd service.
Troubleshooting repoconfig.sh: No such file or directory
Unlike typical cosmos-sdk chains where the daemon is a single executable file, Agoric's use of cosmos-sdk depends on many components of agoric-sdk at runtime. Copying agd to /usr/local/bin or the like is unlikely to produce a working installation. For more detail, see: #7825
Troubleshooting Cannot find dependency ... in systemd
If you have LimitNOFILE=4096 in your systemd unit file, change it to LimitNOFILE=65536. For more detail, see #7817
Specifying --upgrade-info for the software upgrade proposal
The ./scripts/gen-upgrade-proposal.sh is designed to aid in composing a agd tx submit-proposal software-upgrade ... command. In particular, it captures package checksums to verify integrity of downloaded software.
agoric-upgrade-17-rc1
The Agoric OpCo engineering team is pleased to publish the agoric-upgrade-17-rc1 release. This release includes updates to Orchestration Core that advance chain orchestration facilities, and also improvements to reduce the storage and memory footprint required of validator nodes.
The following new features are included in this release:
- #9064: orchestration can create Interchain accounts (ICAs) on a host chain
- #9890: query support in orchestration flows
- #10029: orchestration account balance queries
- #10032: app.toml configuration for vat snapshot and delivery transcript JS database entry retention
- #10036: app.toml configuration for vat snapshot and delivery transcript file archiving
- #9900: reduce contract bundle size
The release contains at least the following fixes:
- #9961: Remotable/Presence garbage collection edge cases
- #10110: [new since RC0] Remove init-chain-info proposal intended for a future release
The full set of changes in this release can be found at #10097 and #10114, and reviewed in detail as agoric-upgrade-16...agoric-upgrade-17-rc1.
Assuming this release satisfies all pre-release/testnet validation checks, it will be promoted to agoric-upgrade-17, and recommended for chains to upgrade from the previous agoric-upgrade-16 release. As a chain-halting upgrade, once approved, all chain validators will need to upgrade from agoric-upgrade-16 to this new version (after the chain halts due to reaching the height required in a governance proposal).
New app configuration
We've added support for a [swingset] section to app.toml for customizing local consensus-independent behavior of the Swingset JavaScript VM. Of particular note are the vat snapshot and delivery transcript retention settings, which can be used to significantly reduce growth of the JS database size.
| Setting | Default value | Other values | Purpose |
|---|---|---|---|
slogfile |
<path to file> | if non-empty, where to write a "slog" (Swingset delivery log file) | |
max-vats-online |
50 | <positive integer> | maximum number of vats to keep loaded in memory |
vat-snapshot-retention |
"operational" | "debug" | "debug" to preserve all vat snapshots in the JS database; "operational" to preserve only the most recent |
vat-transcript-retention |
"default" | "archival", "operational" | "archival" to preserve all vat delivery transcript spans in the JS database; "operational" to drop those preceding the most recent vat snapshot; "default" to derive from pruning ("archival" with pruning = "nothing", otherwise "operational") |
vat-snapshot-archive-dir |
<path to directory> | if non-empty, where to write gzipped vat snapshot files | |
vat-transcript-archive-dir |
<path to directory> | if non-empty, where to write gzipped historical (closed) vat delivery transcript span files |
Any new app.toml file will be initialized with the new section, but we recommend that the following be added to existing files (and then customized per your needs):
###############################################################################
### SwingSet Configuration ###
###############################################################################
[swingset]
# The path at which a SwingSet log "slog" file should be written.
# If relative, it is interpreted against the application home directory
# (e.g., ~/.agoric).
# May be overridden by a SLOGFILE environment variable, which if relative is
# interpreted against the working directory.
slogfile = ""
# The maximum number of vats that the SwingSet kernel will bring online. A lower number
# requires less memory but may have a negative performance impact if vats need to
# be frequently paged out to remain under this limit.
max-vats-online = 50
# Retention of vat snapshots, with values analogous to those of export
# 'artifactMode' (cf.
# https://github.com/Agoric/agoric-sdk/blob/master/packages/swing-store/docs/data-export.md#optional--historical-data ).
# * "debug": keep all snapshots
# * "operational": keep only the last snapshot
vat-snapshot-retention = "operational"
# Retention of vat transcript spans, with values analogous to those of export
# 'artifactMode' (cf.
# https://github.com/Agoric/agoric-sdk/blob/master/packages/swing-store/docs/data-export.md#optional--historical-data ).
# * "archival": keep all transcript spans
# * "operational": keep only necessary transcript spans (i.e., since the
# last snapshot of their vat)
# * "default": determined by 'pruning' ("archival" if 'pruning' is "nothing",
# otherwise "operational")
vat-transcript-retention = "default"
# Archival of gzipped vat snapshots.
vat-snapshot-archive-dir = ""
# Archival of historical (i.e., closed) vat transcript spans to gzipped files.
vat-transcript-archive-dir = ""State-sync
State-sync snapshots now only include minimal data to restore a node, and the new configuration settings will help further reduce requirements of non-archival nodes. However, there may still be continued performance issues related to state-sync. In particular, we've observed that on some deployments, the snapshot taking and restoring process can take multiple hours, require about 20GB of temporary free disk space, and 16GB of memory.
Cosmos Upgrade Handler Name
Below is the cosmos upgrade handler name for this release. This is the name that can be used in governance proposals to deploy this upgrade.
Cosmos Upgrade Handler Name: agoric-upgrade-17
Tags
Below is the git information related to this software release. Note the git tag does not always match the cosmos upgrade handler name.
Git Tag: agoric-upgrade-17-rc1
Git Commit: 5259430561693bfcf58516c3ea54123895859708
@agoric/cosmos package version: 0.35.0-u17.1
Docker: ghcr.io/agoric/agoric-sdk:49
As shown in go.mod this release is based on:
ibc-go v6.3.1
cosmos-sdk v0.46.16
cometbft v0.34.30
How to upgrade
Presuming that your node is running agoric-upgrade-16, once the upgrade height for a subsequent proposal to upgrade to agoric-upgrade-17-rc1 has been reached, your node will halt automatically allowing you to upgrade the agoric stack.
Prerequisites
Install supported versions of Go, Node.js, and a compiler such as gcc or clang as documented in the README.
Make sure that the environment running the agd service has the same Node.js version as the environment used for building. In particular, if using nvm to manage Node.js version, the service environment should enable nvm and use the same version.
Building
# (stop the agd service)
cd agoric-sdk
git fetch --all
git checkout agoric-upgrade-17-rc1
git clean -xdf && git submodule foreach --recursive git clean -xdf
./bin/agd build
# (start the agd service)
Do not copy the agd script or Go binary to another location. If you would like to have an executable agd in another location, then create a symlink in that location pointing to agoric-sdk/bin/agd.
Troubleshooting module ... was compiled against a different Node.js version and SyntaxError issues
The agd service is not using the same version of Node.js as the one used when building. The most likely cause is that nvm was used to manage the Node.js version in the shell when building. Either install the required version of Node.js globally using the system's package manager, or enable nvm in the environment of the agd service.
Troubleshooting repoconfig.sh: No such file or directory
Unlike typical cosmos-sdk chains where the daemon is a single executable file, Agoric's use of cosmos-sdk depends on many components of agoric-sdk at runtime. Copying agd to /usr/local/bin or the like is unlikely to produce a working installation. For more detail, see: #7825
Troubleshooting Cannot find dependency ... in systemd
If you have LimitNOFILE=4096 in your systemd unit file, change it to LimitNOFILE=65536. For more detail, see #7817
Specifying --upgrade-info for the software upgrade proposal
The ./scripts/gen-upgrade-proposal.sh is designed to aid in composing a agd tx submit-proposal software-upgrade ... command. In particular, it captures package checksums to verify integrity of downloaded software.
agoric-upgrade-17-rc0
The Agoric OpCo engineering team is pleased to publish the agoric-upgrade-17-rc0 release. This release includes updates to Orchestration Core that advance chain orchestration facilities, and also improvements to reduce the storage and memory footprint required of validator nodes.
The following new features are included in this release:
- #9064: orchestration can create Interchain accounts (ICAs) on a host chain
- #9890: query support in orchestration flows
- #10029: orchestration account balance queries
- #10032: app.toml configuration for vat snapshot and delivery transcript JS database entry retention
- #10036: app.toml configuration for vat snapshot and delivery transcript file archiving
- #9900: reduce contract bundle size
The release contains at least the following fixes:
- #9961: Remotable/Presence garbage collection edge cases
The full set of changes in this release can be found at #10097 and reviewed in detail as agoric-upgrade-16...agoric-upgrade-17-rc0.
Assuming this release satisfies all pre-release/testnet validation checks, it will be promoted to agoric-upgrade-17, and recommended for chains to upgrade from the previous agoric-upgrade-16 release. As a chain-halting upgrade, once approved, all chain validators will need to upgrade from agoric-upgrade-16 to this new version (after the chain halts due to reaching the height required in a governance proposal).
New app configuration
We've added support for a [swingset] section to app.toml for customizing local consensus-independent behavior of the Swingset JavaScript VM. Of particular note are the vat snapshot and delivery transcript retention settings, which can be used to significantly reduce growth of the JS database size.
| Setting | Default value | Other values | Purpose |
|---|---|---|---|
slogfile |
<path to file> | if non-empty, where to write a "slog" (Swingset delivery log file) | |
max-vats-online |
50 | <positive integer> | maximum number of vats to keep loaded in memory |
vat-snapshot-retention |
"operational" | "debug" | "debug" to preserve all vat snapshots in the JS database; "operational" to preserve only the most recent |
vat-transcript-retention |
"default" | "archival", "operational" | "archival" to preserve all vat delivery transcript spans in the JS database; "operational" to drop those preceding the most recent vat snapshot; "default" to derive from pruning ("archival" with pruning = "nothing", otherwise "operational") |
vat-snapshot-archive-dir |
<path to directory> | if non-empty, where to write gzipped vat snapshot files | |
vat-transcript-archive-dir |
<path to directory> | if non-empty, where to write gzipped historical (closed) vat delivery transcript span files |
Any new app.toml file will be initialized with the new section, but we recommend that the following be added to existing files (and then customized per your needs):
###############################################################################
### SwingSet Configuration ###
###############################################################################
[swingset]
# The path at which a SwingSet log "slog" file should be written.
# If relative, it is interpreted against the application home directory
# (e.g., ~/.agoric).
# May be overridden by a SLOGFILE environment variable, which if relative is
# interpreted against the working directory.
slogfile = ""
# The maximum number of vats that the SwingSet kernel will bring online. A lower number
# requires less memory but may have a negative performance impact if vats need to
# be frequently paged out to remain under this limit.
max-vats-online = 50
# Retention of vat snapshots, with values analogous to those of export
# 'artifactMode' (cf.
# https://github.com/Agoric/agoric-sdk/blob/master/packages/swing-store/docs/data-export.md#optional--historical-data ).
# * "debug": keep all snapshots
# * "operational": keep only the last snapshot
vat-snapshot-retention = "operational"
# Retention of vat transcript spans, with values analogous to those of export
# 'artifactMode' (cf.
# https://github.com/Agoric/agoric-sdk/blob/master/packages/swing-store/docs/data-export.md#optional--historical-data ).
# * "archival": keep all transcript spans
# * "operational": keep only necessary transcript spans (i.e., since the
# last snapshot of their vat)
# * "default": determined by 'pruning' ("archival" if 'pruning' is "nothing",
# otherwise "operational")
vat-transcript-retention = "default"
# Archival of gzipped vat snapshots.
vat-snapshot-archive-dir = ""
# Archival of historical (i.e., closed) vat transcript spans to gzipped files.
vat-transcript-archive-dir = ""State-sync
State-sync snapshots now only include minimal data to restore a node, and the new configuration settings will help further reduce requirements of non-archival nodes. However, there may still be continued performance issues related to state-sync. In particular, we've observed that on some deployments, the snapshot taking and restoring process can take multiple hours, require about 20GB of temporary free disk space, and 16GB of memory.
Cosmos Upgrade Handler Name
Below is the cosmos upgrade handler name for this release. This is the name that can be used in governance proposals to deploy this upgrade.
Cosmos Upgrade Handler Name: agoric-upgrade-17
Tags
Below is the git information related to this software release. Note the git tag does not always match the cosmos upgrade handler name.
Git Tag: agoric-upgrade-17-rc0
Git Commit: a890aea9fb60e71b80a7e04a2ab08aa80db85fdb
@agoric/cosmos package version: 0.35.0-u17.0
Docker: ghcr.io/agoric/agoric-sdk:48
As shown in go.mod this release is based on:
ibc-go v6.3.1
cosmos-sdk v0.46.16
cometbft v0.34.30
How to upgrade
Presuming that your node is running agoric-upgrade-16, once the upgrade height for a subsequent proposal to upgrade to agoric-upgrade-17-rc0 has been reached, your node will halt automatically allowing you to upgrade the agoric stack.
Prerequisites
Install supported versions of Go, Node.js, and a compiler such as gcc or clang as documented in the README.
Make sure that the environment running the agd service has the same Node.js version as the environment used for building. In particular, if using nvm to manage Node.js version, the service environment should enable nvm and use the same version.
Building
# (stop the agd service)
cd agoric-sdk
git fetch --all
git checkout agoric-upgrade-17-rc0
git clean -xdf && git submodule foreach --recursive git clean -xdf
./bin/agd build
# (start the agd service)
Do not copy the agd script or Go binary to another location. If you would like to have an executable agd in another location, then create a symlink in that location pointing to agoric-sdk/bin/agd.
Troubleshooting module ... was compiled against a different Node.js version and SyntaxError issues
The agd service is not using the same version of Node.js as the one used when building. The most likely cause is that nvm was used to manage the Node.js version in the shell when building. Either install the required version of Node.js globally using the system's package manager, or enable nvm in the environment of the agd service.
Troubleshooting repoconfig.sh: No such file or directory
Unlike typical cosmos-sdk chains where the daemon is a single executable file, Agoric's use of cosmos-sdk depends on many components of agoric-sdk at runtime. Copying agd to /usr/local/bin or the like is unlikely to produce a working installation. For more detail, see: #7825
Troubleshooting Cannot find dependency ... in systemd
If you have LimitNOFILE=4096 in your systemd unit file, change it to LimitNOFILE=65536. For more detail, see #7817
Specifying --upgrade-info for the software upgrade proposal
The ./scripts/gen-upgrade-proposal.sh is designed to aid in composing a agd tx submit-proposal software-upgrade ... command. In particular, it captures package checksums to verify integrity of downloaded software.
agoric-upgrade-16av-rc4
This release provides materials to upgrade the vaultFactory and install new auctioneer contract.
Important Fixes
- fix: Make the auction schedule robust when adding collateral types #8301
- When governed parameters are reset, re-calculate the schedule if there's no next auction scheduled, or if the "next" auction has already passed.
- Enable the Economic Committee to restart the auction scheduler through a governed auction parameter change.
- auction scheduler robustness #9759
- When an auction settles, calculate the distribution of proceeds more robustly and transparently.
- feat: catch all exceptions in auction wakers #8438
- Auctions are more robust to errors that arise while handling timer wakeups.
- Inter Protocol vaults should allow adjustments that don't increase debt when mint limit <= debt outstanding · #9837
To make an on-chain proposal
Presuming bundles are installed (see below) use a tool such as the CoreEval Proposal tab of the DCF Cosmos Proposal Builder.
From Assets below, download 2 permit / script pairs, one for add-auction and one for upgrade-vaults. Drop add-auction-permit.json and add-auction.js on the form, hit Add more files, and then drop the other pair, upgrade-vaults-permit.json and upgrade-vaults.js:
Then sign and submit the governance proposal transaction.
To Install Bundles
Use a tool such as the Install Bundle tab of the Cosmos Proposal Builder
For each of the 4 bundles, drop it onto the form (note the storage cost) and submit:
b1-7db1fff8ee711a4bffe21a81f731d540c3d88c671b2ba6a457c4c9677df123008c310633f738b0eae3042e9593bb2569d0ca59a3f1d12752bcc2124c3240ee97.jsonb1-31bf1ef20dd190a9f541471bc15238a51f621ff2340e6eb225214b9fdf3970f2bc3bc4fe151a79ef2e740b2679cf03f553b89a828da704dec9ccba9463fc3f79.jsonb1-47c15fc48569fde3afe4e4947f877242d2d6367c07876951acea99a20d9c890974f3d237f22b5033a84c5e3d506acc6e899e519590a8557d49d6d43611dc9c65.jsonb1-8859b141114716b24cca1bd8bc14f81c066880556b5e94eb1767c0ca3d5f4917a6762dcbab85d84bcdf06ba64179a34bfd7cbb5b43c9ab459b5abe09aeb7cdd9.json
Bundle provenance:
- ci job: core-eval-scripts.zip
SHA256d9c47e3870926035a30784872d9b0171a7906ccdec38795e1d7f068093bcaf4e
Relevant changes from upgrade-16 to -rc0
- 8722 provisionPool re-register notifiers by @Chris-Hibbert in #9481
- Master integration into dev-upgrade-16 by @iomekam in #9461
- Remove scaled price authority upgrade by @Chris-Hibbert in #9585
- feat: add the ability to override param values by @Chris-Hibbert in #9829
- auction scheduler robustness by @turadg in #9759
- Update a3p-integration after upgrade 16 by @Chris-Hibbert in #9878
- adding collateral by @turadg in #7892
- fix(vaultFactory): don't prevent repayment based on DebtLimit by @dckc in #9907
- upgrade vaults by @Chris-Hibbert in #9283
- Add a coreEval for vaults auctions and test in a3p by @Chris-Hibbert in #9911
- robustify allManagersDo by @Chris-Hibbert in #9833
- fix: giving collateral should not change totalDebt by @dckc in #9873
Full Changelog: agoric-upgrade-16...agoric-upgrade-16av-rc0
Relevant Changes from -rc0 to -rc1
- Ratio.quantize() shouldn't increase precision unnecessarily by @Chris-Hibbert in #9926
- Specify a bundle to use when upgrading auctions by @Chris-Hibbert in #9937
Full Changelog: agoric-upgrade-16av-rc0...agoric-upgrade-16av-rc1
Relevant changes from -rc1 to -rc2
- ci(integration): add a step to archive core eval scripts by @LuqiPan in #9929
- get auction instance from promise returned by addAuction by @Chris-Hibbert in #9944
Full Changelog: agoric-upgrade-16av-rc1...agoric-upgrade-16av-rc2
Relevant changes from -rc2 to -rc3
- feat: add null upgrade of vaultFactoryGovernor to upgrade-vaults.js by @Chris-Hibbert in #9953
Full Changelog: agoric-upgrade-16av-rc2...agoric-upgrade-16av-rc3
Changes from -rc3
- feat: update auction in agoricNames, test that the boardId changed by @Chris-Hibbert in #9970
Full Changelog: agoric-upgrade-16av-rc3...agoric-upgrade-16av-rc4
Contributors
Assets 12
agoric-upgrade-16av
This release provides materials to upgrade the vaultFactory and install new auctioneer contract.
Important Fixes
- fix: Make the auction schedule robust when adding collateral types #8301
- When governed parameters are reset, re-calculate the schedule if there's no next auction scheduled, or if the "next" auction has already passed.
- Enable the Economic Committee to restart the auction scheduler through a governed auction parameter change.
- auction scheduler robustness #9759
- When an auction settles, calculate the distribution of proceeds more robustly and transparently.
- feat: catch all exceptions in auction wakers #8438
- Auctions are more robust to errors that arise while handling timer wakeups.
- Inter Protocol vaults should allow adjustments that don't increase debt when mint limit <= debt outstanding · #9837
To make an on-chain proposal
Presuming bundles are installed (see below) use a tool such as the CoreEval Proposal tab of the DCF Cosmos Proposal Builder.
From Assets below, download 2 permit / script pairs, one for add-auction and one for upgrade-vaults. Drop add-auction-permit.json and add-auction.js on the form, hit Add more files, and then drop the other pair, upgrade-vaults-permit.json and upgrade-vaults.js:
Then sign and submit the governance proposal transaction.
To Install Bundles
Use a tool such as the Install Bundle tab of the Cosmos Proposal Builder
For each of the 4 bundles, drop it onto the form (note the storage cost) and submit:
b1-7db1fff8ee711a4bffe21a81f731d540c3d88c671b2ba6a457c4c9677df123008c310633f738b0eae3042e9593bb2569d0ca59a3f1d12752bcc2124c3240ee97.jsonb1-31bf1ef20dd190a9f541471bc15238a51f621ff2340e6eb225214b9fdf3970f2bc3bc4fe151a79ef2e740b2679cf03f553b89a828da704dec9ccba9463fc3f79.jsonb1-47c15fc48569fde3afe4e4947f877242d2d6367c07876951acea99a20d9c890974f3d237f22b5033a84c5e3d506acc6e899e519590a8557d49d6d43611dc9c65.jsonb1-8859b141114716b24cca1bd8bc14f81c066880556b5e94eb1767c0ca3d5f4917a6762dcbab85d84bcdf06ba64179a34bfd7cbb5b43c9ab459b5abe09aeb7cdd9.json
Bundle provenance:
- ci job: core-eval-scripts.zip
SHA256d9c47e3870926035a30784872d9b0171a7906ccdec38795e1d7f068093bcaf4e
Relevant changes from upgrade-16 to -rc0
- 8722 provisionPool re-register notifiers by @Chris-Hibbert in #9481
- Master integration into dev-upgrade-16 by @iomekam in #9461
- Remove scaled price authority upgrade by @Chris-Hibbert in #9585
- feat: add the ability to override param values by @Chris-Hibbert in #9829
- auction scheduler robustness by @turadg in #9759
- Update a3p-integration after upgrade 16 by @Chris-Hibbert in #9878
- adding collateral by @turadg in #7892
- fix(vaultFactory): don't prevent repayment based on DebtLimit by @dckc in #9907
- upgrade vaults by @Chris-Hibbert in #9283
- Add a coreEval for vaults auctions and test in a3p by @Chris-Hibbert in #9911
- robustify allManagersDo by @Chris-Hibbert in #9833
- fix: giving collateral should not change totalDebt by @dckc in #9873
Full Changelog: agoric-upgrade-16...agoric-upgrade-16av-rc0
Relevant Changes from -rc0 to -rc1
- Ratio.quantize() shouldn't increase precision unnecessarily by @Chris-Hibbert in #9926
- Specify a bundle to use when upgrading auctions by @Chris-Hibbert in #9937
Full Changelog: agoric-upgrade-16av-rc0...agoric-upgrade-16av-rc1
Relevant changes from -rc1 to -rc2
- ci(integration): add a step to archive core eval scripts by @LuqiPan in #9929
- get auction instance from promise returned by addAuction by @Chris-Hibbert in #9944
Full Changelog: agoric-upgrade-16av-rc1...agoric-upgrade-16av-rc2
Relevant changes from -rc2 to -rc3
- feat: add null upgrade of vaultFactoryGovernor to upgrade-vaults.js by @Chris-Hibbert in #9953
Full Changelog: agoric-upgrade-16av-rc2...agoric-upgrade-16av-rc3
Changes from -rc3
- feat: update auction in agoricNames, test that the boardId changed by @Chris-Hibbert in #9970
Full Changelog: agoric-upgrade-16av-rc3...agoric-upgrade-16av-rc4
Contributors
Assets 12
agoric-upgrade-16av-rc3
This release provides materials to upgrade the vaultFactory and install new auctioneer contract.
Important Fixes
- fix: Make the auction schedule robust when adding collateral types #8301
- When governed parameters are reset, re-calculate the schedule if there's no next auction scheduled, or if the "next" auction has already passed.
- Enable the Economic Committee to restart the auction scheduler through a governed auction parameter change.
- auction scheduler robustness #9759
- When an auction settles, calculate the distribution of proceeds more robustly and transparently.
- feat: catch all exceptions in auction wakers #8438
- Auctions are more robust to errors that arise while handling timer wakeups.
- Inter Protocol vaults should allow adjustments that don't increase debt when mint limit <= debt outstanding · #9837
To make an on-chain proposal
Presuming bundles are installed (see below) use a tool such as the CoreEval Proposal tab of the DCF Cosmos Proposal Builder.
From Assets below, download 2 permit / script pairs, one for add-auction and one for upgrade-vaults. Drop add-auction-permit.json and add-auction.js on the form, hit Add more files, and then drop the other pair, upgrade-vaults-permit.json and upgrade-vaults.js:
Then sign and submit the governance proposal transaction.
To Install Bundles
Use a tool such as the Install Bundle tab of the Cosmos Proposal Builder
For each of the 4 bundles, drop it onto the form (note the storage cost) and submit:
Bundle provenance:
- ci job: core-eval-scripts.zip
SHA256d8c9f53a8c0ef4e0717ce00e1e3cd592200b959382f956c0915cc15e43f36b4d
Relevant changes from upgrade-16 to -rc0
- 8722 provisionPool re-register notifiers by @Chris-Hibbert in #9481
- Master integration into dev-upgrade-16 by @iomekam in #9461
- Remove scaled price authority upgrade by @Chris-Hibbert in #9585
- feat: add the ability to override param values by @Chris-Hibbert in #9829
- auction scheduler robustness by @turadg in #9759
- Update a3p-integration after upgrade 16 by @Chris-Hibbert in #9878
- adding collateral by @turadg in #7892
- fix(vaultFactory): don't prevent repayment based on DebtLimit by @dckc in #9907
- upgrade vaults by @Chris-Hibbert in #9283
- Add a coreEval for vaults auctions and test in a3p by @Chris-Hibbert in #9911
- robustify allManagersDo by @Chris-Hibbert in #9833
- fix: giving collateral should not change totalDebt by @dckc in #9873
Full Changelog: agoric-upgrade-16...agoric-upgrade-16av-rc0
Relevant Changes from -rc0 to -rc1
- Ratio.quantize() shouldn't increase precision unnecessarily by @Chris-Hibbert in #9926
- Specify a bundle to use when upgrading auctions by @Chris-Hibbert in #9937
Full Changelog: agoric-upgrade-16av-rc0...agoric-upgrade-16av-rc1
Relevant changes from -rc1 to -rc2
- ci(integration): add a step to archive core eval scripts by @LuqiPan in #9929
- get auction instance from promise returned by addAuction by @Chris-Hibbert in #9944
Full Changelog: agoric-upgrade-16av-rc1...agoric-upgrade-16av-rc2
Relevant changes from -rc2 to -rc3
- feat: add null upgrade of vaultFactoryGovernor to upgrade-vaults.js by @Chris-Hibbert in #9953
Full Changelog: agoric-upgrade-16av-rc2...agoric-upgrade-16av-rc3