Pharos Production / Review brief
Wallet & FinTech Brief: Map Who Can Change State
The most useful architecture question is often who can change a balance, sign a transaction or replace privileged code. Map those powers before comparing a feature list.
Original editorial worksheet · Updated
- Use it for
- Define trust boundaries for wallets, smart contracts, digital assets or payment-connected software.
- Output
- A blank, editable record with evidence fields and ownership.
- Tool behavior
- The CSV is a static download. No project details are requested or submitted.
Set the boundary before comparing
Separate the user interface, application records, signing system and external settlement network. Record which source is authoritative for each state. A wallet interface, a custody service and a payment adapter are different scopes even when their screens look similar. Tokenization and banking workflows also depend on decisions made outside the software delivery team.
Ask for an explicit account of privileged actions and recovery. A smart contract audit covers an agreed code and version scope; it does not automatically cover the application, signing procedures or a later upgrade. Keep those review boundaries visible in the proposal.
The evidence record
Use one row per review area. The role is a starting point; assign a named owner in your project. Attach a sanitized reference and retain unresolved questions until a reviewer has a supported answer.
| Review area | Evidence to attach | Suggested role |
|---|---|---|
| Authority | Authoritative balance or state source and allowed writers | System owner |
| Signing | Key custody, signing permissions and approval process | Security owner |
| Contracts | Network, deployed addresses, code version and upgrade rights | Contract owner |
| Payments | External status mapping and unresolved-outcome handling | Payments owner |
| Recovery | Restoration boundary, evidence and escalation route | Operations owner |
| Acceptance | Scoped review reports and unresolved dependencies | Receiving reviewer |
The CSV adds assigned owner, evidence reference, status, unresolved question and review date columns. Every row starts as draft.
A fictional example
In a fictional wallet project, an application can report "submitted" while settlement remains unknown. A useful brief names the authoritative lookup, the transaction identity and the team investigating the discrepancy. It does not turn an unavailable response into a successful payment.
Use the record in a review
- Draw each system boundary and name its authoritative records.
- Identify privileged roles and the actions they can perform.
- Attach evidence requirements to signing, upgrades and failure recovery.
- Assign external legal, commercial and provider prerequisites to their actual owners.
Download the blank CSV and keep the completed version with your project records.
Source and limits
This worksheet covers engineering scope. It makes no determination about licensing, custody obligations, investment suitability or regulatory approval. Do not put keys, seed phrases or private account data in the record.
OpenZeppelin Contracts: Access Control. Documents contract permissions and roles. It does not validate the architecture of a particular wallet or payment system.
Source reviewed 9 November 2026. The suggested fields are this site's editorial method, not an external certification standard.