Hello community,
I am exploring the potential of a Zcash community grant and would appreciate constructive feedback.
The project would develop an open source technical architecture. specification for developers building noncustodial applications that help users spend or convert selected amounts of shielded ZEC.
The project would also establish a properly scoped legal-review process with qualified U.S. digital-asset counsel.
The central question is:
How can an application assist a user in moving a selected amount of shielded ZEC toward a regulated payment, conversion or off-ramp environment without taking control of the user’s funds or unnecessarily exposing unrelated financial activity?
The grant would focus on research, architecture, privacy boundaries and legal-review preparation.
The problem
A developer building around shielded ZEC must make architectural choices that are not answered simply by describing a product as “self-custodial” or “noncustodial.”
Relevant questions include:
- Where are spending keys created and stored?
- Where are transactions constructed and signed?
- Does an application server merely provide data, or can it influence transaction destinations?
- What account and organizational information is stored locally?
- What information is visible to wallet, network and infrastructure providers?
- What happens when value moves from the shielded environment to a regulated third party?
- Can the application interrupt, redirect, recover or independently move funds?
- Does the provider receive subscription fees, transaction-based compensation or routing revenue?
- Which technical or operational changes could alter the application’s custody and regulatory analysis?
Developers need a practical way to identify and document these boundaries before requesting product-specific legal advice.
Proposed scope
1. Representative Privacy and Trust Architecture Specification
This deliverable would define a bounded reference architecture for a consumer application that helps a user organize, spend, or convert selected amounts of shielded ZEC.
Its purpose would be to document how the architecture distributes trust across the user, application provider, wallet infrastructure, network services, and regulated third parties.
Rather than classifying the application only as “custodial” or “noncustodial,” the specification would examine where each component falls across several distinct trust boundaries.
These would include:
- Spending authority: Who possesses the keys or authority required to move funds?
- Transaction influence: Who can construct, modify, route, delay, reject, or broadcast a transaction?
- Information access: Who can view account data, transaction details, viewing information, identity data, or locally stored application state?
- Infrastructure dependency: Which wallets, network services, APIs, or providers must remain available and trustworthy?
- Off-ramp control: Who selects, manages, or controls the relationship with the conversion, payment, or regulated off-ramp provider?
- User verification: What can the user independently inspect before signing or completing a transaction?
- User exit: Can the user bypass or replace the application provider without losing access to funds or essential account information?
The specification would include a trust-boundary matrix showing how different architectural choices change the level and type of trust the user places in each participant.
For example, one configuration may keep encrypted application state and transaction construction entirely in the browser, reducing the information and transaction-construction trust placed in the application provider. A different configuration may rely on the provider’s server to request quotes, select destinations, construct transactions, or coordinate an off-ramp relationship, creating additional trust and disclosure boundaries even when the provider never possesses the user’s spending keys.
The architecture would be informed by existing Zcash wallet, browser-wallet, and network infrastructure, but it would not be permanently tied to one integration before its capabilities and limitations have been technically validated.
This also means the second deliverable should probably become the actual matrix and diagrams produced from this specification, rather than repeating the same analysis. A cleaner division would be:
- Privacy and Trust Architecture Specification — defines the architecture and evaluation framework.
- Trust-Boundary Matrix and Data-Flow Map — visually applies that framework to each participant and system component.
2. Privacy, State and Third-Party Boundary Map
This deliverable would provide diagrams and a structured matrix showing what information may be available to each participant in the representative architecture.
Participants may include:
- The user
- The application frontend
- The application server
- The wallet or browser-wallet provider
- Zcash network infrastructure
- Holders of viewing information
- A swap, bridge or conversion provider
- A regulated off-ramp or payment provider
- Public blockchain observers
- Network-level observers
The analysis would address:
- Local encrypted state versus server-side storage and logging
- Spending authority
- Transaction-construction and broadcasting responsibilities
- Transaction metadata
- Viewing capabilities and selective disclosure
- Amount and timing disclosures
- Third-party account linkage
- Transitions between shielded and transparent environments
- Privacy claims that an application should avoid making to users
The purpose would be to document the privacy and control boundaries of one representative architecture rather than attempt to catalog every possible Zcash product model.
3. Legal Review Scoping and Counsel Engagement
Before making specific legal conclusions or promising a particular public legal opinion, the project would seek to engage qualified U.S. digital-asset counsel with relevant experience in money transmission, noncustodial software and digital-asset payment infrastructure.
The initial legal work would be intended to:
- Confirm that qualified counsel is available and willing to review the architecture
- Complete an initial consultation
- Present the architecture and boundary map to counsel
- Identify the federal and state legal questions requiring analysis
- Determine what form of public legal research or issue-spotting guidance counsel can responsibly review
- Obtain a proposed scope, estimate and limitations for the legal work
- Define the appropriate attorney-reviewed deliverable for the formal grant application
Potential areas for review may include:
- Custody and practical control
- The distinction between providing software and conducting money transmission
- Federal money-transmission considerations
- Relevant state-level considerations
- Sanctions and recordkeeping responsibilities
- Relationships with regulated third-party providers
- The effect of transaction-based compensation or routing involvement
The purpose would not be to promise that a particular architecture automatically avoids regulation.
Any resulting legal material would clearly distinguish between general educational research and legal advice for a specific developer or company.
The exact legal-review deliverable would be finalized only after qualified counsel has reviewed the proposed scope and confirmed what can responsibly be completed and published.
The project would seek involvement from:
- A technically qualified Zcash engineer or reviewer
- Qualified U.S. digital-asset regulatory counsel
Recommendations from the community would be valuable.
Community feedback requested
Before preparing a formal application, @ZcashGrants I would especially appreciate feedback on the following questions:
- Does this address a genuine problem for developers exploring noncustodial Zcash applications, or do existing resources already cover it adequately?
- Which technical boundaries should receive the most attention: key custody, transaction construction, viewing capabilities, local state, network metadata or third-party integrations?
- Would the representative architecture and privacy-boundary map be useful without production code?
- Would an attorney-reviewed legal issue framework be useful to Zcash builders, provided its exact scope is determined with counsel before it is promised as a grant deliverable?
- Are there particular legal questions that developers repeatedly encounter when integrating shielded ZEC with regulated third parties?
- Which Zcash developers, wallet teams or infrastructure specialists should be consulted as technical reviewers or intended users?
- Are there attorneys or organizations with relevant Zcash, financial-privacy or noncustodial-software experience that the project should approach?
Direct inquiry is welcome. The purpose of this thread is to determine whether the proposed research would provide genuine value to the Zcash ecosystem before defining the formal milestones, budget and legal-review scope.
Thank you