ZIG : Zcash Integration Guardrail - A compatibility linter for Zcash configs & RPC usage

[Creativesonchain]

Hi @readymouse , thank you so much for your feedback!

@readymouse

Team/Scope Mismatch: The team member responsibilities mention deliverables not in the proposal (frostd packaging?). These appear to be from a different project entirely. Can you clarify which project this team is actually working on?

Sorry for the error. The “frostd packaging” line was a copy/paste typo left over from our earlier FROST multisig draft (TSSK): . We have corrected that now. Thank you.

@readymouse

Profile Accuracy: The tool’s entire value depends on correct compatibility data, but there’s no validation methodology. How will you ensure the profiles are accurate before release? A compatibility checker that gives wrong answers is worse than no tool at all.

We agree with your point. ZIG will be designed to be conservative and easy to verify.

What we will do in v1:

1. Every rule will be traceable to a public source
   Each compatibility entry (RPC or config rule) will include:

• a short note (“why this is flagged”), and
• a link/reference to the public source used (docs/spreadsheet/repo notes).

2. Unknown is never treated as safe
   If an RPC method or config key is not covered by the profile data, ZIG will label it “manual review required” (not “OK”).This prevents false confidence.

3. Regression tests using fixed examples
   We will ship a small set of example configs + RPC manifests with expected outputs and run them in continuous integration so profile changes don’t silently change results.

4. Release checklist includes profile review
   Before tagging v1.0.0, we will validate that:

• profiles pass schema checks,
• profiles include sources,
• example-based tests pass.

This is how we keep ZIG reliable even though it’s based on compatibility data.

@readymouse

Missing Technical Background: For a tool requiring deep knowledge of zcashd→Zebra compatibility differences, I don’t see evidence that the team has direct experience with zcashd or zebra. Can you point to previous work with the Zcash infrastructure?

We are creatives onchain - a group of developers that love solving cool infra problems. We are not claiming to be maintainers of zcashd or Zebra. The reason this is still feasible for this team is that ZIG v1 is not a node implementation or protocol project. It is a tooling project that:

• parses config files,
• reads a list of RPC method names a project actually uses,
• compares those against documented compatibility information, and
• produces a report + CI-friendly exit codes.

To avoid relying on “tribal knowledge,” we’re deliberately keeping v1 to:

• a clearly defined set of common config keys and commonly used RPCs, and
• “manual review required” for anything outside that set.

@readymouse

90-Day Maintenance Window: I do like that there is a line about maintaining it past the initial build, this is important. I guess the hope is that the community will step up to maintain it afterwards. Without ongoing updates, this tool becomes misleading as the ecosystem evolves.

You’re right that a compatibility tool can become stale.

To reduce that risk:

• profiles will include a last-updated date, and
• ZIG will warn when profile data is old or when the user targets a stack identifier that isn’t covered.

The proposal includes 90 days of maintenance to fix early issues and keep profiles aligned during initial adoption. Even after that window, ZIG is designed to fail safely (warn/require manual review) rather than silently reporting “OK” based on outdated data.

Please kindly let us know if this is clear. We are happy to answer any more questions you may have.
Thank you.