Tag generated using command make release-tag.

Tag generated using command make release-tag.

Database Migrations

Note that downgrading from v0.8.1 to previous tapd versions is not presently supported. You should create backups of tapd database state before upgrading to tapd v0.8.1.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://raw.githubusercontent.com/lightninglabs/taproot-assets/main/scripts/keys/roasbeef.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.8.1.sig and manifest-v0.8.1.txt are in the current directory) with:

gpg --verify manifest-roasbeef-v0.8.1.sig manifest-v0.8.1.txt

You should see the following if the verification was successful:

gpg: Signature made Wed Sep 30 17:35:20 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

In addition to time-stamping the git tag with OpenTimestamps, we also timestamp the manifest file along with its signature. Two files are included in our release artifacts: manifest-roasbeef-v0.8.1.sig.ots and manifest-v0.8.1.txt.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands:

ots verify manifest-roasbeef-v0.8.1.sig.ots -f manifest-roasbeef-v0.8.1.sig
ots verify manifest-v0.8.1.txt.ots -f manifest-v0.8.1.txt

Alternatively, the OpenTimestamps website can be used to verify these timestamps if one doesn't have a bitcoind instance accessible locally.

Assuming you are using the OpenTimestamps ots-git-gpg-wrapper you can verify the timestamp of the git tag by verifying the tag as explained in Verifying the Release Binaries.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved.
The release binaries are compiled with go1.26.3, which is required by verifiers to arrive at the same ones.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.8.1
gpg: Signature made Tue Sep 15 18:55:00 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

Verifying the Docker Images

To verify the tapd and tapcli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

$ docker run --rm --entrypoint="" lightninglabs/taproot-assets:v0.8.1 /verify-install.sh v0.8.1
$ OK=$?
$ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
$ docker run lightninglabs/taproot-assets [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming
that vendor.tar.gz and tapd-source-v0.8.1.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz
tar -xvzf tapd-source-v0.8.1.tar.gz
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.1" ./cmd/tapd
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.1" ./cmd/tapcli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

Release Notes

⚡ ⚡ ⚡ See the in-repo release notes for a detailed list of high-level changes made since v0.8.0. ⚡ ⚡ ⚡

Database Migrations

TODO

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://raw.githubusercontent.com/lightninglabs/taproot-assets/main/scripts/keys/roasbeef.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.8.1-rc3.sig and manifest-v0.8.1-rc3.txt are in the current directory) with:

gpg --verify manifest-roasbeef-v0.8.1-rc3.sig manifest-v0.8.1-rc3.txt

You should see the following if the verification was successful:

gpg: Signature made Wed Sep 30 17:35:20 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

In addition to time-stamping the git tag with OpenTimestamps, we also timestamp the manifest file along with its signature. Two files are included in our release artifacts: manifest-roasbeef-v0.8.1-rc3.sig.ots and manifest-v0.8.1-rc3.txt.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands:

ots verify manifest-roasbeef-v0.8.1-rc3.sig.ots -f manifest-roasbeef-v0.8.1-rc3.sig
ots verify manifest-v0.8.1-rc3.txt.ots -f manifest-v0.8.1-rc3.txt

Alternatively, the OpenTimestamps website can be used to verify these timestamps if one doesn't have a bitcoind instance accessible locally.

Assuming you are using the OpenTimestamps ots-git-gpg-wrapper you can verify the timestamp of the git tag by verifying the tag as explained in Verifying the Release Binaries.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved.
The release binaries are compiled with go1.26.3, which is required by verifiers to arrive at the same ones.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.8.1-rc3
gpg: Signature made Tue Sep 15 18:55:00 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

Verifying the Docker Images

To verify the tapd and tapcli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

$ docker run --rm --entrypoint="" lightninglabs/taproot-assets:v0.8.1-rc3 /verify-install.sh v0.8.1-rc3
$ OK=$?
$ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
$ docker run lightninglabs/taproot-assets [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming
that vendor.tar.gz and tapd-source-v0.8.1-rc3.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz
tar -xvzf tapd-source-v0.8.1-rc3.tar.gz
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.1-rc3" ./cmd/tapd
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.1-rc3" ./cmd/tapcli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

TODO

Contributors (Alphabetical Order)

TODO

Database Migrations

TODO

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://raw.githubusercontent.com/lightninglabs/taproot-assets/main/scripts/keys/roasbeef.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.8.1-rc2.sig and manifest-v0.8.1-rc2.txt are in the current directory) with:

gpg --verify manifest-roasbeef-v0.8.1-rc2.sig manifest-v0.8.1-rc2.txt

You should see the following if the verification was successful:

gpg: Signature made Wed Sep 30 17:35:20 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

In addition to time-stamping the git tag with OpenTimestamps, we also timestamp the manifest file along with its signature. Two files are included in our release artifacts: manifest-roasbeef-v0.8.1-rc2.sig.ots and manifest-v0.8.1-rc2.txt.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands:

ots verify manifest-roasbeef-v0.8.1-rc2.sig.ots -f manifest-roasbeef-v0.8.1-rc2.sig
ots verify manifest-v0.8.1-rc2.txt.ots -f manifest-v0.8.1-rc2.txt

Alternatively, the OpenTimestamps website can be used to verify these timestamps if one doesn't have a bitcoind instance accessible locally.

Assuming you are using the OpenTimestamps ots-git-gpg-wrapper you can verify the timestamp of the git tag by verifying the tag as explained in Verifying the Release Binaries.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved.
The release binaries are compiled with go1.26.3, which is required by verifiers to arrive at the same ones.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.8.1-rc2
gpg: Signature made Tue Sep 15 18:55:00 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

Verifying the Docker Images

To verify the tapd and tapcli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

$ docker run --rm --entrypoint="" lightninglabs/taproot-assets:v0.8.1-rc2 /verify-install.sh v0.8.1-rc2
$ OK=$?
$ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
$ docker run lightninglabs/taproot-assets [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming
that vendor.tar.gz and tapd-source-v0.8.1-rc2.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz
tar -xvzf tapd-source-v0.8.1-rc2.tar.gz
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.1-rc2" ./cmd/tapd
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.1-rc2" ./cmd/tapcli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

TODO

Contributors (Alphabetical Order)

TODO

Database Migrations

TODO

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://raw.githubusercontent.com/lightninglabs/taproot-assets/main/scripts/keys/roasbeef.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.8.1-rc1.sig and manifest-v0.8.1-rc1.txt are in the current directory) with:

gpg --verify manifest-roasbeef-v0.8.1-rc1.sig manifest-v0.8.1-rc1.txt

You should see the following if the verification was successful:

gpg: Signature made Wed Sep 30 17:35:20 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

In addition to time-stamping the git tag with OpenTimestamps, we also timestamp the manifest file along with its signature. Two files are included in our release artifacts: manifest-roasbeef-v0.8.1-rc1.sig.ots and manifest-v0.8.1-rc1.txt.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands:

ots verify manifest-roasbeef-v0.8.1-rc1.sig.ots -f manifest-roasbeef-v0.8.1-rc1.sig
ots verify manifest-v0.8.1-rc1.txt.ots -f manifest-v0.8.1-rc1.txt

Alternatively, the OpenTimestamps website can be used to verify these timestamps if one doesn't have a bitcoind instance accessible locally.

Assuming you are using the OpenTimestamps ots-git-gpg-wrapper you can verify the timestamp of the git tag by verifying the tag as explained in Verifying the Release Binaries.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved.
The release binaries are compiled with go1.26.3, which is required by verifiers to arrive at the same ones.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.8.1-rc1
gpg: Signature made Tue Sep 15 18:55:00 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

Verifying the Docker Images

To verify the tapd and tapcli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

$ docker run --rm --entrypoint="" lightninglabs/taproot-assets:v0.8.1-rc1 /verify-install.sh v0.8.1-rc1
$ OK=$?
$ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
$ docker run lightninglabs/taproot-assets [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming
that vendor.tar.gz and tapd-source-v0.8.1-rc1.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz
tar -xvzf tapd-source-v0.8.1-rc1.tar.gz
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.1-rc1" ./cmd/tapd
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.1-rc1" ./cmd/tapcli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

TODO

Contributors (Alphabetical Order)

TODO

Database Migrations

Note that downgrading from v0.8.0 to previous tapd versions is not presently supported. You should create backups of tapd database state before upgrading to tapd v0.8.0.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://raw.githubusercontent.com/lightninglabs/taproot-assets/main/scripts/keys/roasbeef.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.8.0.sig and manifest-v0.8.0.txt are in the current directory) with:

gpg --verify manifest-roasbeef-v0.8.0.sig manifest-v0.8.0.txt

You should see the following if the verification was successful:

gpg: Signature made Wed Sep 30 17:35:20 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

In addition to time-stamping the git tag with OpenTimestamps, we also timestamp the manifest file along with its signature. Two files are included in our release artifacts: manifest-roasbeef-v0.8.0.sig.ots and manifest-v0.8.0.txt.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands:

ots verify manifest-roasbeef-v0.8.0.sig.ots -f manifest-roasbeef-v0.8.0.sig
ots verify manifest-v0.8.0.txt.ots -f manifest-v0.8.0.txt

Alternatively, the OpenTimestamps website can be used to verify these timestamps if one doesn't have a bitcoind instance accessible locally.

Assuming you are using the OpenTimestamps ots-git-gpg-wrapper you can verify the timestamp of the git tag by verifying the tag as explained in Verifying the Release Binaries.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved.

The release binaries are compiled with go1.26.3, which is required by verifiers to arrive at the same ones.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

Finally, you can also verify the tag itself with the following command:

$ git verify-tag v0.8.0
gpg: Signature made Tue Sep 15 18:55:00 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <[email protected]>" [ultimate]

Verifying the Docker Images

To verify the tapd and tapcli binaries inside the docker images against the signed, reproducible release binaries, there is a verification script in the image that can be called (before starting the container for example):

$ docker run --rm --entrypoint="" lightninglabs/taproot-assets:v0.8.0 /verify-install.sh v0.8.0
$ OK=$?
$ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
$ docker run lightninglabs/taproot-assets [command-line options]

Building the Contained Release

Users are able to rebuild the target release themselves without having to fetch any of the dependencies. In order to do so, assuming
that vendor.tar.gz and tapd-source-v0.8.0.tar.gz are in the current directory, follow these steps:

tar -xvzf vendor.tar.gz
tar -xvzf tapd-source-v0.8.0.tar.gz
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.0" ./cmd/tapd
go install -v -mod=vendor -ldflags "-X github.com/lightninglabs/taproot-assets/build.Commit=v0.8.0" ./cmd/tapcli

The -mod=vendor flag tells the go build command that it doesn't need to fetch the dependencies, and instead, they're all enclosed in the local vendor directory.

Additionally, it's now possible to use the enclosed release.sh script to bundle a release for a specific system like so:

make release sys="linux-arm64 darwin-amd64"

⚡️⚡️⚡️ OK, now to the rest of the release notes! ⚡️⚡️⚡️

Release Notes

See the in-repo release notes for a detailed list of high-level changes made since v0.7.2.

What's Changed

• chore: merge 0-8-0-staging into main by @jtobin in #1876
• build(deps): bump the go_modules group across 3 directories with 1 update by @dependabot[bot] in #1868
• build(deps): bump the go_modules group across 4 directories with 1 update by @dependabot[bot] in #1880
• garbage collect zero-value UTXOs by @darioAnongba in #1832
• tapdb: introduce sqlTime helper by @darioAnongba in #1883
• tapcfg: validate SQLite temp dir at startup and add opt out flag by @ffranr in #1886
• tapdb: switch proof cache to size-based limits and add deep size estimation by @ffranr in #1870
• docs: add metadata standard for Stablecoins by @jamaljsr in #1542
• make: use Docker named volumes for ~10x faster local linting by @Roasbeef in #1892
• chore: readme tlc by @jtobin in #1895
• Improve HTLC interceptor setup handling and fix itest flake by @ffranr in #1899
• tapgarden: copy MintingBatches defensively by @jtobin in #1903
• proof: improve re-org proof replacement, strengthen error handling, expand test coverage by @ffranr in #1896
• Persist agreed quotes in RFQ service by @darioAnongba in #1863
• Orphan UTXO filter and limit by @darioAnongba in #1905
• Delete channel alias scids when quotes expire by @GeorgeTsagk in #1710
• rfq: add InternalPortfolioPilot and initial ResolveRequest wiring by @ffranr in #1912
• tapgarden: enhance MintingBatch.Copy tests with seedlings coverage by @ffranr in #1918
• tapgarden: wait for finalizebatch to complete by @jtobin in #1917
• rfq: refactor and unify incoming quote handling with accept interface and tests by @ffranr in #1913
• makefile: mount Git metadata for worktree support in Docker lint runs by @ffranr in #1925
• taprpc+scripts: detect Podman wrapper and preserve Docker UID mapping by @ffranr in #1928
• docs: add bug fixes and prebroadcast validation changes to release notes by @ffranr in #1926
• rfq+rfqmsg: add structured price oracle error codes by @jtobin in #1766
• itest: fix flakiness in full value send test by @ffranr in #1944
• itest: drop shared timeout contexts to reduce slow-CPU flakes by @ffranr in #1947
• ci: parallelize integration tests using matrix strategy by @ffranr in #1936
• itest: remove more shared timeout context across test files by @ffranr in #1948
• build: bump version to v0.7.99-alpha by @Roasbeef in #1931
• docs: add docs for how burns work within the protocol and codebase by @Roasbeef in #1786
• ci: parallelize itest job tranches using all available CPUs by @ffranr in #1949
• rfq: delegate accept quote validation to PortfolioPilot by @ffranr in #1935
• tapgarden: flake reduction by @jtobin in #1945
• chore: fix docker workflow by @jtobin in #1956
• rfq: allow nil price oracle for non-RFQ users by @ffranr in #1955
• Add Claude Code GitHub Workflow by @Roasbeef in #1961
• taprpc: add BakeMacaroon RPC and tapcli support by @ffranr in #1960
• rfq: query asset rates via PortfolioPilot by @ffranr in #1954
• rfq/portfolio-pilot: propagate context through order + message handling APIs by @ffranr in #1959
• rfq: remove oracle resp Validate method and update error handling by @ffranr in #1971
• Speed up unit CI with optional verbosity and package parallelism by @ffranr in #1970
• Pre‑broadcast proof verification: validate more, skip only what can’t be known yet by @ffranr in #1969
• Forwarding history by @darioAnongba in #1921
• Add RPC portfolio pilot integration, config, docs, and itests by @ffranr in #1962
• agents: add CLAUDE.md by @darioAnongba in #1972
• Make proof verification explicit via verified proof API by @ffranr in #1974
• CI: shard unit-race across 4 jobs to cut runtime by @ffranr in #1975
• tapchannel: align to latest LND version by @darioAnongba in #1958
• rfq: add price oracle certificate verification by @jtobin in #1775
• rfq: add macaroon option for price oracle authentication by @jtobin in #1978
• refactor: isolate RPC server plumbing into rpcserver package by @ffranr in #1963
• ci: use claude opus and allow PR branch checkout by @darioAnongba in #1993
• healthcheck: add TLS check by @djkazic in #1985
• test: custom channel itests by @darioAnongba in #1986
• docs: update external group key guide by @jtobin in #1996
• ListAssets pagination by @darioAnongba in #1995
• fix: rename sweep-orphan-utxos to disable-sweep-orphan-utxos by @darioAnongba in #2002
• ci: add custom channels workflow by @darioAnongba in #1997
• itest: separate tapd instance logs into per-node files by @darioAnongba in #1988
• itest: port custom channel tests from lightning-terminal by @darioAnongba in #2001
• build: bump Go to 1.25.5 and LND to latest main by @darioAnongba in #2016
• Enhance isAssetInvoice check by @GeorgeTsagk in #2009
• ci: misc refactoring by @jtobin in #2017
• chore: add 'docker-verify' target to makefile by @jtobin in #1953
• Asset Wallet Backup Support by @GeorgeTsagk in #1980
• itest: forwarding history by @darioAnongba in #2021
• FetchAsset RPC by @darioAnongba in #2014
• ci: fix itest log zipping and unhide log directories by @darioAnongba in #2029
• Add test coverage for ComputeView by @GeorgeTsagk in #1919
• rpcserver: populate group key or asset_id in DecodeAssetPayReq by @darioAnongba in #2036
• authmailbox: reconnect on non-graceful stream errors by @jtobin in #2035
• authmailbox: add message cleanup and RemoveMessage RPC by @GeorgeTsagk in #2020
• itest: add invoice/quote expiry mismatch test by @jtobin in #2042
• itest: add passive assets custom channel test by @jtobin in #2043
• tapsend: harden AssertAnchorTimeLocks by @jtobin in #2044
• authmailbox: bump timeout to decrease flake incidence by @jtobin in #2046
• Fixing populating genesis info by @sergey3bv in #2039
• rfq: add limit constraints and quote-level enforcement to rfq negotiation by @jtobin in #2048
• multi: forward-port burn by group key from staging by @darioAnongba in #2062
• supplyverifier: add unit tests for Verifier by @rxbryan in #2063
• Improving itest clean-up by @sergey3bv in #2057
• chore: use --match 'v*' in git describe to ignore submodule tags by @jtobin in #2037
• build: bump lnd to latest master by @darioAnongba in #2067
• rfqmsg+rfq: add execution policy to rfq negotiation by @jtobin in #2049
• authmailbox: fix race between auth handshake and message delivery by @jtobin in #2072
• tapgarden: fix race in assertNewBatchFrozen by @jtobin in #2059
• itest: deflake custom channel liquidity cleanup by @GeorgeTsagk in #2069
• tapgarden: make proof notification and tx confirmation order deterministic by @jtobin in #2073
• itest: wait for HTLC settlement before checking balances by @jtobin in #2071
• itest: add graph sync assertions to limit_constraints test by @jtobin in #2068
• tapdb: surface underlying tx retry errors and fix per-attempt rollback scope by @darioAnongba in #2088
• taprpc: clarify proto docs for OutPoint, ReceiveEvent, ScriptKey by @jtobin in #2087
• multi: bump lnd to master, pin ANCHORS in custom_channels itest by @GeorgeTsagk in #2082
• rfq+rfqmsg: add fill quantity negotiation and constraint validation by @jtobin in #2050
• authmailbox: wait for multiSub reconnect in restart test by @jtobin in #2090
• rfq+tapdb: persist peer-accepted sell quotes by @jtobin in #2051
• multi: make AddFederationServer idempotent on duplicate by @jtobin in #2092
• Supply verifier tests by @rxbryan in #2074
• tapgarden: surface non-critical custodian errors to subscribers by @kaldun-tech in #2070
• rpcserver: add optional constraint fields to AddInvoice by @jtobin in #2053
• docs: expand example portfolio pilot by @jtobin in #2056
• asset: validate element count in AltLeavesDecoder by @jtobin in #2097
• universe: replace backend map with LRU cache by @jtobin in

Note truncated.