Core principle
In a normal wallet, a successful compromise can become an immediate loss event. If an attacker gets access to the device or a user approves the wrong transfer, funds can move out very quickly. Slowlyy changes that assumption by separating transfer creation from transfer release.
The main idea is simple: a transfer request can exist before a transfer is allowed to leave.
Delayed outgoing transfers
Slowlyy introduces a waiting period between the moment an outgoing transfer is requested and the moment it can actually be broadcast or finalized. That delay creates a response window.
- A user or attacker may be able to initiate a request.
- The request does not automatically mean immediate release.
- The delay period allows review, detection, and intervention.
- The final movement of funds happens only after the delay condition is satisfied.
Why this changes the risk profile
Many wallet defenses focus on who controls keys, who signs transactions, or which device is trusted. Those are important, but they do not change the speed of loss once something goes wrong. Slowlyy adds a different layer: time.
Time matters because a user who notices suspicious activity after two minutes still has a chance to act if the wallet is designed not to release funds immediately.
Time verification and release conditions
The whitepaper describes a model in which date and time checks are not trusted solely to the local device clock. The goal is to reduce the risk that local clock manipulation could be used to bypass the waiting period.
- External time sources can be used to validate release conditions.
- The release check is intended to fail closed if validation is inconsistent.
- The wallet logic should block release rather than guess when trust conditions are unclear.
Failure behavior
A security system should be judged not only by ideal operation, but by how it behaves when something breaks. The security model described for Slowlyy prefers blocking release over releasing under uncertainty.
- If validation fails, the safer default is to block the transfer.
- If expected trust signals do not match, the safer default is to block the transfer.
- If the environment looks compromised, the delay window exists to buy reaction time.
Self-custody boundary
Slowlyy is intended to remain a self-custody product. The user still keeps control of their own keys. The security model is not based on handing control to a centralized custodian. Instead, it modifies the release behavior of outgoing transfers while preserving user ownership.
Current product state
The live testnet demonstrates the delayed-transfer idea with a 30 minute delay. The planned mainnet product is intended to support configurable delays from 3 to 30 days, along with stronger hardening and more refined recovery-oriented behavior.