Project Summary
We are requesting $12,750 to build a public negative-fixture pack and CLI runner for Zcash shielded hardware-wallet and cold-signing flows.
The project helps signer implementations test whether they reject hostile companion-app payloads before producing a sign
Project Description
Zcash shielded hardware-wallet and cold-signing flows often rely on a host wallet or companion app to prepare transaction data and pass signing information to a separate signer.
This project focuses on the trust boundary between the companion app and the signer. The signer may keep private keys safe, but user safety can still fail if the companion app causes the signer to display one set of transaction details while signing a different payload.
We will build a small open-source fixture pack and runner that tests this failure class. The tool will include valid baseline fixtures, hostile fixtures, a machine-readable fixture schema, a CLI runner, a mock signer adapter, a reference adapter stub, and Markdown/JSON reports.
The project is intentionally narrow. It does not build a hardware wallet, wallet app, SDK, PCZT interoperability suite, ZIP conformance suite, hosted service, certification program, or audit replacement.
Proposed Problem
Hardware-wallet and cold-signing implementations need to handle a hostile or incorrect companion app safely.
A signer should not produce a signature when:
- The name of the person shown doesn’t match the information in the signed payload.
- the amount shown doesn’t match what was agreed to when signing.
- the fee shown on the screen doesn’t match the transaction I’m trying to approve;
- there is no text to rewrite, so the output is empty
- it seems the problem is with the network or the context used for signing, maybe the right one isn’t being used.
- malformed or unexpected fields are accepted;
The signing process takes place before the user has fully approved everything.
Some sellers might already have their own tests and plans in place to check things. These are helpful, but they usually only work for one specific situation. What’s missing is a small, public set of tests that focus on what happens when things go wrong with clear-signing, especially in hostile situations. This is something that Zcash doesn’t have right now.
Proposed Solution
We’re going to create the Zcash Hostile-Companion Clear-Signing Fixture Pack.
The project will provide:
- a short hostile-companion threat model;
- a versioned fixture schema;
- a 12-fixture corpus;
- a CLI runner;
- a mock signer adapter;
- a reference adapter stub;
- Markdown and JSON reports;
- setup, adapter, and fixture authoring documentation.
So, a team can basically copy the repository, use the test data to check how it works with a fake adapter, look at the results, and then hook up their own tester or simulator to the adapter. This way, they can see how everything works together and make sure it’s all good.
Solution Format
Open-source software and test artifacts.
Deliverables will include:
THREAT_MODEL.mdfixtures/schema.jsonfixtures/valid/fixtures/hostile/- CLI runner
- mock signer adapter
- reference adapter stub
ADAPTER_SPEC.md- Markdown and JSON report output
- sample report
- setup and usage documentation
Dependencies
No external vendor integration is required.
Technical dependencies:
- public Zcash documentation and signing-flow references;
- standard open-source development tools;
- a local development environment for CLI and fixture testing;
- a permissive open-source repository.
Project dependencies:
- no upstream merge requirement;
- no vendor approval requirement;
- no hardware device requirement;
- no hosted infrastructure requirement.
Technical Approach
The fixture runner will be implemented as a small CLI tool.
The runner will:
- load fixture metadata from a versioned schema;
Next, you need to call a signer adapter using the fixture payload. - receive a structured adapter response;
- compare the response with the expected fixture result;
If a hostile setup creates a unique pattern, the test should be failed. - generate Markdown and JSON reports;
- return CI-friendly exit codes.
Fixture results will use a small vocabulary:
ACCEPT— valid baseline fixture accepted;REJECT_BEFORE_SIGNATURE— hostile fixture rejected before signing;- The signer had an issue and couldn’t provide a signature, so they stopped the process to prevent any problems.
- The signer doesn’t support this type of fixture yet.
The way we connect things will be based on how they work and won’t depend on a specific language. A team that signs things can use this connection to wrap around their simulator, emulator, or test runner, and then send back a response in a format called JSON to the command line tool.
Example adapter response:
{ “fixture_id”: “recipient-mismatch-001”, “result”: “REJECT_BEFORE_SIGNATURE”, “signature_produced”: false, “error_code”: “RECIPIENT_MISMATCH” }
The first release will include 12 fixtures:
- Valid baseline shielded payment.
- Valid baseline shielded payment with memo metadata.
- Recipient mismatch.
- Amount mismatch.
- Fee mismatch.
- Hidden extra output.
- Wrong network.
- Wrong signing context.
- Sign-before-confirmation.
- Malformed memo-related payload.
- Unknown critical signing-package field.
- Malformed or truncated signing package.
The test package doesn’t promise to guarantee complete security for signers. Instead, it checks a specific set of scenarios where a companion might try to fake a signature.
Upstream Merge Opportunities
N/A
Hardware/Software Costs (USD)
$0
Hardware/Software Justification
N/A
Service Costs (USD)
$0
Service Costs Justification
N/A
Compensation Costs (USD)
$12,750
Compensation Costs Justification
Estimated effort:
- threat model, fixture schema, and seed fixtures: 50 hours;
We spent around 65 hours working on a few key things: the CLI runner, the adapter interface, reports, and a mock adapter. - full fixture corpus, documentation, QA, and handoff: 55 hours.
Total estimated effort: 170 hours
Rate: $75/hour
Total compensation: $12,750
Total Budget (USD)
$12,750
Previous Funding
No
Previous Funding Details
nil
Other Funding Sources
No
Other Funding Sources Details
No response
Implementation Risks
- Signing-package formats may evolve.
The fixture schema will be versioned so future fixture formats can be added without breaking the first release. - Different signers may expose different simulator interfaces.
The way we plan to connect things will be based on how they work together and won’t depend on a specific language. We’ll include a test version and a basic example, but we won’t rely on any particular company’s system to make it work. - The scope could be mistaken for an audit or certification tool.
The documentation will clearly state that the project is a negative-fixture pack only. It does not certify hardware wallets or replace audits.
The first set of data won’t include every single problem that signers might have.The first release focuses on 12 clear hostile-companion cases. The fixture authoring guide will make it easy to add more cases later.
Potential Side Effects
The biggest problem is that people might rely too much on the fixture report to feel safe.
To lower the risk, we’ll make sure all reports clearly say that the fixture pack only looks at the cases that are included. Just because the fixture pack passes doesn’t mean the signer is completely secure or has been fully audited.
You don’t need to use your own money or private information to use the fixture pack. The tool won’t send any transactions or connect to the main network, so you’re safe. It’s a completely self-contained system, designed to help you test and develop without any risk.
Success Metrics
The project is successful when:
- A public repository has been made available under a license that allows for free use and modification.
- The hostile-companion threat model is complete.
- The fixture schema is documented.
The command line interface runner is what executes the fixtures, and it does this against a mock adapter. - The fixture corpus includes 12 fixtures.
- Reports are generated in Markdown and JSON.
- CI-friendly exit codes are supported.
- A reference adapter stub shows how external signer simulators can connect.
A team responsible for signing can go through the adapter guide to learn how to link up their test runner on their own. This way, they can set it up to work with their system.
This project can be used without needing approval from others, permission from suppliers, or relying on external systems. It’s completely independent and ready to go.
Startup Funding (USD)
$0
Startup Funding Justification
N/A
- Milestone: 1
Amount (USD): 3,750
Expected Completion Date: 2026-07-15
User Stories:
- As someone who creates hardware wallets, I need a straightforward plan for testing so I can see what each test is checking for. This way, I can make sure my wallet is safe and works well.
- As a reviewer, I want a short threat model so that I can evaluate the project scope without treating it as an audit or certification tool.
Deliverables:
-
THREAT_MODEL.md -
fixtures/schema.json -
repository structure
-
expected-result vocabulary
-
4 seed fixtures
Acceptance Criteria: -
We assume that the host wallet or companion app can’t be trusted to keep our information safe.
-
The setup plan allows for both good and bad test scenarios.
The collection has a minimum of four fixtures. -
Every difficult or opposing situation comes with a predicted reason for why it might not work out.
-
Milestone: 2
Amount (USD): 4,750
Expected Completion Date: 2026-07-29
User Stories:
- As a signer implementer, I want a CLI runner so that I can test fixtures against a signer adapter.
- When I’m checking things, I want to get reports in Markdown and JSON so I can see which cases worked, which didn’t, and which ones couldn’t be checked. This way, I can easily look at the results and understand what’s going on.
Deliverables:
- CLI runner
- adapter interface
- mock signer adapter
- reference adapter stub
- Markdown report output
- JSON report output
- CI-compatible exit codes
Acceptance Criteria:
-
A reviewer is able to use just one command with the mock adapter.
-
The report displays whether each fixture has passed or failed.
-
Hostile fixtures fail if the adapter reports that a signature was produced.
-
The adapter interface is documented.
-
The example adapter stub demonstrates how to link a signer simulator or an external test runner without needing approval from the vendor.
-
Milestone: 3
Amount (USD): 4,250
Expected Completion Date: 2026-08-12
User Stories:
- As a hardware-wallet or cold-signing team, I want a focused hostile-companion fixture corpus so that I can test clear-signing failure cases consistently.
- To make it easier for people like me to help out in the future, I think we need some instructions on how to create new test cases, especially the really tough ones that can cause problems.
Deliverables:
- 12 total fixtures
- sample Markdown report
- sample JSON report
- adapter guide
- fixture authoring guide
- final README
- final handoff report
Acceptance Criteria:
- The collection contains a minimum of two reliable standard tests.
- The collection has a minimum of 10 aggressive or unfriendly companion fixtures.
- Every difficult or opposing situation we face has a clear reason why it might not work out as planned.
- Reports are generated in Markdown and JSON.
- The documentation explains scope, non-goals, setup, adapter usage, and future fixture extension.