- Wallet architecture and migration strategy
Case studies
Blockchain
Panther Wallet
mypanther.ioProduct type:Custodial crypto wallet (mobile, web, administrative interface)
System state:Live system with real users and funds under custody
01
Launch context
Panther Wallet initially launched with a non-custodial wallet model, where users retained direct control over their funds.
As the product evolved, requirements expanded to include:
⌵Centralized custody of user assets,
⌵Crypto payments and card flows,
⌵Coordinated system management.
This required a fundamental architectural transition while the system was already live, with active users and balances. Once custody was introduced, the system assumed full responsibility for:
•Private key management,
•Transaction execution,
•Controlled operational actions affecting user funds.
There was no rollback path for architectural decisions.
02
Core risk
Primary risk
Migrating from non-custodial to custodial wallet architecture transfers irreversible responsibility for user funds to the system operator.
Secondary effects
Migrating from non-custodial to custodial wallet architecture transfers irreversible responsibility for user funds to the system operator.
⌵Operational correctness replaces user-side security
⌵Trust depends on internal controls rather than user autonomy
⌵Mistakes have financial and reputational consequences
This was a custody responsibility risk, not a feature or interface risk.
03
Decisions
Early decisions
•The non-custodial architecture was treated as a temporary foundation, not a final state.
•Custodial logic was introduced as a separate responsibility layer, not a partial extension.
•System control was designed as an explicit governance mechanism.
Explicitly rejected:
mixing custodial and non-custodial assumptions within a single control flow.
Locked constraints
•the system became fully responsible for private key management and transaction execution,
•user autonomy over funds was replaced by managed custody,
•architectural decisions could no longer be reverted without disrupting live balances.
These constraints were accepted as inherent to custodial systems.
04
Validation
Threat and failure mode mapping before irreversible steps.
Test strategy focused on abuse paths and operational correctness.
Review gates before deployment and before any privilege changes.
05
Outcome
What stabilized
⌵Custody transition was completed without user-facing disruptions.
⌵Custodial logic was introduced as a separate responsibility layer, not a partial extension.
⌵System control was designed as an explicit governance mechanism.
The system favors managed responsibility over user-side autonomy.
What Remained Risky
•Custody risk cannot be eliminated, only managed.
•Responsibility scales with user balances and activity.
•External regulatory and compliance expectations evolve independently of system logic.
These risks were accepted as structural.
06
Ownership
What we owned
- Custodial responsibility model
- Separation of user access and system execution
What the Client Owned
- Business decision to operate a custodial wallet
- Ongoing operational governance
- Legal and regulatory responsibility