Yea I see what you’re saying. The original wording starts with a conclusion that the system is noncustodial. If i understand correctly the better framing is Representative Privacy and Trust Architecture Specification, that way it captures transaction influence, viewing access, provider control and the off-ramp relationship.
My revision would then be
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.