Working template · KYC and wallets
Blockchain integration readiness worksheet
Record an owner, evidence and a scoped decision for each of 12 checks. Keep an unresolved question open until someone can reproduce the supporting result.
For product owners, engineering leads and receiving teams reviewing a KYC-backed wallet flow. Print this page or copy the record fields into your review system.
Go to the 12 checksDefine the scope first
A review applies to one described integration.
Write down the application release, provider configuration, supported wallet and chain, test environment and review date. Reference sanitized evidence. Keep secrets and identity documents in their approved systems.
Template version 1 ·
How to use the record
- Assign the person who can make each decision. The developer producing evidence and the person accepting it may be different people.
- Run the relevant checks in an authorized test environment and link the observed results. A proposed test is not a passed test.
- Use supported, open or not applicable with a written reason. Avoid a percentage score that hides a blocking gap.
- Give every open item an owner and next action. Repeat the affected checks when a provider, policy or release changes.
Pharos Production's blockchain development services cover application and wallet engineering. This worksheet helps define the evidence to request when reviewing that kind of integration. It does not claim any system has already passed.
The working sheet
12 checks to record
Boundary
Define the decision being reviewed
Name the user journey, environment and release revision. State which business action depends on the identity result and which system can permit it.
Evidence to request: A flow diagram with an explicit allow, hold or deny decision and its owner.
Result: supported / open / not applicable, with reason.
Boundary
Separate provider and application states
Map provider outcomes to application states, including pending and manual review. Specify how a new verification attempt relates to the previous one.
Evidence to request: A versioned state map and a test fixture for each supported outcome.
Result: supported / open / not applicable, with reason.
KYC events
Verify authentic notifications
Use the chosen provider's documented verification scheme. Test a valid notification and a deliberately altered body before applying any business change.
Evidence to request: Sanitized test output showing accepted authentic input and rejected altered input.
Result: supported / open / not applicable, with reason.
KYC events
Handle duplicate delivery
Deliver the same test event twice, including concurrently if your architecture allows it. Check that the business effect occurs once and the repeat is recorded.
Evidence to request: A receipt or processing record linked to the observed final application state.
Result: supported / open / not applicable, with reason.
KYC events
Resolve late or conflicting results
Exercise a late callback after a newer verification attempt or manual decision. Apply a documented conflict rule instead of treating receipt order as authority.
Evidence to request: An event sequence, the expected final state and a named route for unresolved conflicts.
Result: supported / open / not applicable, with reason.
KYC events
Recover after a delivery failure
In an authorized test environment, make the receiver temporarily unavailable. Check the provider's retry or resend behavior and how missing updates are found.
Evidence to request: Delivery history plus a recovery record that ties the event to application state.
Result: supported / open / not applicable, with reason.
Wallet
Recheck a changed account or chain
For an EIP-1193 provider, change the selected account and chain. Confirm that the application updates the relevant context before continuing a sensitive workflow.
Evidence to request: A test record for accountsChanged and chainChanged, including the resulting application state.
Result: supported / open / not applicable, with reason.
Wallet
Bind the wallet proof to the session
If the flow uses Sign-In with Ethereum, verify the signed message against the expected domain, address, chain and nonce. Test a reused nonce and a mismatched context.
Evidence to request: A verification record with sensitive material removed and explicit negative-case results.
Result: supported / open / not applicable, with reason.
Wallet
Keep connection and identity decisions separate
State whether, and how, a wallet address is bound to a verified application user. Exercise a changed wallet after verification and a verification that remains pending.
Evidence to request: An application policy and end-to-end tests of the binding boundary.
Result: supported / open / not applicable, with reason.
Release
Identify the exact chain and deployment
Record the intended network, chain ID, contract addresses and application release. Check the displayed environment and the configured endpoints against that record.
Evidence to request: A deployment record with configuration values and revision identifiers, without secrets.
Result: supported / open / not applicable, with reason.
Release
Define what a completed action means
Document how the application distinguishes submitted, confirmed and failed actions. Apply the selected network's confirmation and reorganization policy where relevant.
Evidence to request: A state-transition test and the policy for the supported network. No universal confirmation count assumed.
Result: supported / open / not applicable, with reason.
Operations
Assign the unresolved work
List gaps, permitted next actions and the person who can close each gap. Record an escalation route and a review date before handing the integration to another team.
Evidence to request: An issue list with owners and a reproducible route back to the supporting artifacts.
Result: supported / open / not applicable, with reason.
Fictional worked example
A verified user changes wallet
In this invented review, application account U-17 has a successful KYC result linked to wallet A. The user then connects wallet B. A callback from an earlier verification attempt arrives after the switch.
Open issue: the team has not shown whether the existing identity decision can authorize wallet B. A successful callback alone does not answer that application-policy question.
Keep check 09 open. Ask the product decision owner to approve the binding rule and request a test that follows both wallet addresses through the delayed callback.
| Field | Example entry |
|---|---|
| Scope | U-17, wallet change A to B, earlier verification callback |
| Evidence available | An illustrative event sequence only. No execution log supplied |
| Missing evidence | Approved identity-to-wallet binding policy and a reproducible test |
| Decision | Open. No release approval inferred |
| Next owner | Product decision owner, with backend and frontend evidence |
What the worksheet leaves to your team
The checks are a review aid, not a security audit or a compliance certification. Provider event names, signing rules, retention requirements and supported networks vary. Replace generic labels with the exact terms used by your integration.
When a contract is part of the flow, use the network and deployment record to scope the smart contract development work. This template does not choose a custody model, approve a transaction or set a universal confirmation threshold.
The published NextCheck KYC platform development case provides context for Pharos Production's verification-platform work. The fictional U-17 example above does not describe that project or its results.
Primary references
- Sumsub webhook documentation: verification notifications, delivery logs and retry or resend behavior.
- EIP-1193 provider specification: chain and account change events for compatible Ethereum providers.
- ERC-4361 Sign-In with Ethereum: message fields and verification requirements for a supported sign-in flow.
- OWASP webhook security guidance: authentication, replay protection and duplicate-event handling.
Sources checked October 18, 2026. Use the current documentation for your chosen provider. These organizations have not reviewed or endorsed this worksheet.
Resource owner
Dmytro Nasyrov, Founder and CTO. This is a reusable review template with a fictional example. It reports no executed client test.
Updated