Dependencies updates for github CI actions

[kushti]

No description provided.

[coveralls]

Coverage Report for CI Build 33626528196

Coverage increased (+0.07%) to 86.961%

Details

• Coverage increased (+0.07%) from the base build.
• Patch coverage: 9 uncovered changes across 5 files (66 of 75 lines covered, 88.0%).
• 5 coverage regressions across 2 files.

Uncovered Changes

File	Changed	Covered	%
ergo-rest/src/api/node.rs	28	23	82.14%
ergotree-interpreter/src/sigma_protocol/fiat_shamir.rs	1	0	0.0%
ergotree-ir/src/ergo_tree.rs	1	0	0.0%
ergotree-ir/src/serialization/sigma_byte_reader.rs	5	4	80.0%
ergotree-ir/src/serialization/sigma_byte_writer.rs	2	1	50.0%
Total (13 files)	75	66	88.0%

Coverage Regressions

5 previously-covered lines in 2 files lost coverage.

File	Lines Losing Coverage	Coverage
ergo-lib/src/wallet/tx_builder.rs	4	93.66%
ergo-chain-types/src/header.rs	1	99.26%

---

Coverage Stats

Relevant Lines:	31650
Covered Lines:	27523
Line Coverage:	86.96%
Coverage Strength:	252705.77 hits per line

---

💛 - Coveralls

[odiseusme]

Reviewed the full diff. Gating npm alpha publication on github.event_name == 'push' is a good fix. I would not approve the branch as-is for two reasons.

First, Cargo.toml replaces core2 0.4.0 with core3 0.1.2 through a package alias. That is not CI housekeeping. The dependency supplies Read/Write/Cursor to sigma-ser, ErgoTree serialization, header serialization, and Fiat–Shamir/signature serialization. Because the imports remain named core2, the production impact appears only in this manifest line.

core3 was first published on 2026-04-15. It has two releases, one already yanked, one crates.io owner, and a one-commit repository. With no workspace Cargo.lock, "0.1.2" admits any future 0.1.x.

I compared its relevant non-std I/O implementation with core2 0.4.0 and found no present serialization-semantic difference for the enabled features. The concern is dependency custody and future resolution, not a demonstrated current byte mismatch. All core2 releases are yanked, so replacement is necessary, but this should be reviewed explicitly. Before the 0.29.0 release I would vendor or move the dependency under Ergo-controlled custody, or choose and audit a mature alternative. An exact pin reduces drift but does not by itself resolve owner/yank risk.

Second, the JS and Swift SPV tests previously required two independent NiPoPoW proofs; both now pass with one. That silently removes multi-proof verifier coverage. Please retain a deterministic two-proof test rather than trading that assertion for network reliability.

One smaller issue: the new Swift/WASM fallback node configurations have no request timeout, so a stalled first node may never reach the fallback.

The PyO3/wasm-bindgen migrations, test-only Rust REST helpers, and npm publish gating otherwise look sound.

[a-shannon]

Reviewed the current c02bc0b head after #918. The functional regressions identified during review are addressed, all current checks are green, and the feature-gated C REST suite passes 7/7 on the exact head. I found no remaining code blocker to merging #916.

The 0.29.0 version, packaging, and release-gate work is being handled in a separate follow-up PR before tagging.