24h
Day reset
Useful for breaking a single-day pattern. Short enough to test the experience without committing to a multi-day lock.
Solo Pacts
A pact is a voluntary lock with a release time.
You choose categories, choose a duration, review what becomes hard to change, and confirm with serious friction. The server records the release timestamp so device clock changes do not end the pact early.
The lifecycle
Five steps. Server-owned timing.
A Solo Pact moves through a fixed lifecycle so the user always knows where they stand and the server always knows what is true.
-
01
Configure
Pick categories: porn, gambling, drugs, ads/trackers, malware/phishing, proxy/VPN/Tor. Pick a duration. Review what becomes hard to change while the pact is active.
-
02
Confirm
The app shows exactly what will be enforced, what release looks like, and what the cooling-off period is. Confirmation requires deliberate friction: this is not a one-tap toggle.
-
03
Lock
The server records the start and release timestamps and signs the pact state. The device starts enforcing locally so filtering keeps working when offline.
-
04
Serve
While the pact is active, blocked attempts increment a counter, tamper events are logged, and offline behavior remains safe. No raw browsing history is collected by default.
-
05
Release
Once the server-verified release time arrives, the pact ends cleanly. A user can renew immediately, change settings, or step away. Emergency release paths exist in between.
Server time owns the lock
Clients are not trusted for unlock timing.
If the device clock is wound forward, if a profile is reinstalled, or if an app is reinstalled, the server still owns the truth about when the pact may release. Local enforcement falls back to the safe state until it can verify.
What the server signs
- Pact identifier and the device that owns it
- Categories and policy bundle in effect
- Start time and release time, anchored to server clock
- Allowed release paths (timer expiry, partner approval, emergency override)
What the device does
- Applies the signed policy locally
- Stays locked while offline rather than failing open
- Reports tamper, bypass, and block-count events when reachable
- Refuses to honor unsigned or expired configuration
Durations
Short enough to start, long enough to matter.
Solo Pact durations are designed for real recovery patterns. Shorter pacts are useful for testing, longer pacts cover real risk windows.
72h
Recovery window
The first MVP target. Long enough to feel real, short enough to commit to without coercion.
7d
Weekly cycle
Aligns with weekly check-ins, partner reports, and real-life accountability rhythms.
30d
Monthly streak
For users who want sustained protection through the highest-risk windows in a typical month.
90d
Quarterly lock
Long-form pact for serious recovery work. Emergency release paths still apply.
Custom
Your duration
Choose a custom period. The same release rules and emergency safeguards apply.
Release paths
Release is a path, never a panic switch.
Every pact has clear, documented ways to end. None of them are a one-tap escape during a moment of impulse.
Timer expiry
The default path. The server-verified release timestamp arrives, the pact ends, the user can renew or change settings.
Delayed emergency unlock
For Solo users without a co-signer, an emergency unlock is requested and held for 24 hours before it takes effect. The pact stays enforced during the window.
Partner approval
When a co-signer is configured, an unblock request can be approved or declined. Coercive-control safeguards apply: visibility, audit, and abuse release paths come first.
Abuse, medical, and legal overrides
Documented escape routes exist for safety reasons: abusive partners, medical or legal emergencies, and device safety. These paths are auditable and never silent.
Pact renewal
Renewing immediately after release is one tap. Extending while a pact is active uses the same friction as creating a new pact.
Account closure
Closing an account follows the same release rules as a pact. There is no quiet bypass through deletion or reinstall.
Tamper handling
Bypass attempts are events, not silences.
A pact that pretends nothing happened during a tamper attempt is not a pact. SentryPact treats bypass-shaped behavior as data the user and any co-signer should see.
Detected on the device
- DNS configuration changes
- VPN profile installs, disables, or changes
- Proxy and tunnel tools spinning up
- Browser switches and extension changes
- Permission revocation
- Clock tampering
- Uninstall attempts
What the user sees
- The event in their own dashboard
- The category and time, never raw URLs
- Optional co-signer alert when configured
- An audit trail that survives reinstall