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 Noncustodial Architecture Specification
This deliverable would define a bounded reference architecture for a consumer application in which the user retains spending authority.
The abstract design specification would document:
- Key-generation and key-storage boundaries
- Client-side and server-side responsibilities
- Transaction-construction, signing and broadcasting boundaries
- Local encrypted application-state requirements
- The transition from shielded ZEC to a regulated third-party environment
- Information exposed at each stage
- Conditions under which the application provider could or could not independently move funds
- Security assumptions
- Dependencies on wallet and network infrastructure
- Unresolved technical questions requiring specialist review
The architecture would be informed by existing Zcash wallet and browser-wallet infrastructure, but it would not be permanently tied to one integration before its capabilities and limitations have been validated.
This would be an abstract technical specification rather than production application code.
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