Join the waitlist
PrivacyTerms
How it works

One app. Three
deliberate views.

Walk through Liberty Lock: set it up once, see what each PIN opens, seal the vault in one tap, and preview the location rules planned for after launch.

Start with setup
Set up once

Four steps, done once, on your phone.

Choose what the vault holds, set your two PINs, decide what Secondary Access shows, and print your recovery kit. Step through it below; the toggles are simulated.

Planned for launchSimulated · fictional data

Turn on the kinds of things the vault should hold. Each type gets its own encrypted container, and nothing is moved or deleted from your phone.

Step 01 · Vault contents

What should live in the vault?

Each type gets its own encrypted container. Turning one on adds it to the vault; it doesn’t move or delete anything on your phone.

Everyday use

The view changes. Protected items don’t leak between states.

Everyday Access shows the app’s everyday view while the vault stays sealed. Your real PIN opens the Secure Vault. A second PIN opens Secondary Access, a separate space holding only ordinary content you chose in advance.

Select a state to replay it · simulated screens · app in development

Conceptual Liberty Lock app simulation. Simulated home screen. The vault is sealed and no protected items are on screen.

Everyday view. The vault stays sealed.

01 — Access states

One app. Three access states. A boundary you control.

Everyday Access and Secondary Access are views. The Secure Vault sits behind an access boundary and opens only with your real PIN.

  1. 01

    Everyday Access

    What the app shows day to day. The vault stays sealed and nothing protected is on screen.

    Surface
  2. 03

    Secondary Access

    What a second PIN opens: an ordinary-looking space holding only content you chose in advance.

    Surface
  3. —

    Access boundary

    Crossing it takes your real PIN. Encryption and platform-protected keys are planned as core constraints.

    Design target
  4. 02

    Secure Vault

    Credentials, recovery phrases, journals, photos and documents you choose to protect.

    Behind the boundary
Conceptual exploded view of the app: Everyday Access and Secondary Access in front, the access boundary behind them, and the Secure Vault behind the boundary.

Simulated screens · conceptual product model

Quick Lock

Seal the vault in one tap, even offline.

The demonstration changes what Liberty Lock shows. It doesn’t imply a network request, remote deletion, control over other apps, or a measured speed.

Planned for launchSimulated · fictional data

Phone offline in this demo · no signal needed

  1. 01Secure Vault open
  2. 02One tap: Quick Lock
  3. 03Vault sealed · everyday view

Seals Liberty Lock only. It doesn’t lock your phone or other apps.

Simulated app screens: the open vault seals and the app returns to its everyday view.
Trusted Signal
Coming later

A rule may change the view without becoming a server-side history.

Trusted Signal is planned for after launch. You’d set rules such as “seal the vault when I leave home.” The design target is that rules are checked on your phone, so the location that triggers a rule isn’t sent to Liberty Lock.

Separate from the proposed Panic Mode, which would share location with contacts you choose

Representation boundary

Readable on the device. Cipher-only across the boundary.

The object changes representation before an optional crossing. The service-side model contains no visual or functional path back to readable content.

Conceptual architecture sequence showing local input, access-state selection, a protected object changing from readable text into a cipher representation, a controlled boundary crossing, limited service scope, and information that never crosses.
Architecture target / guided sequenceLocal control. A changed representation. Limited service scope.
Trust zone A · local deviceUser device
Optional local ruleDEVICE CONTEXT
Access-state controllerPROTECTEDSelected on device
Secure Vault
PRIVATE NOTE
Readable only inside this trust zone
Planned key protectionPLATFORM DEPENDENT
Device edgeControlled boundary
8F  2C  A1  7D  9B  44
Encrypted material only where an optional feature requires it
Limited zone B · externalService scope
Optional encrypted material
8F  2C  A1  7D  9B  44
Stored or processed without a readable representation

No reverse controlThe service-side model contains no key or decrypt action.

Outside intended readable scope
  • Vault content
  • Key material
  • Local context rules
Stage 01 / 07A rule begins on the device.

Optional context is intended to be evaluated locally rather than becoming a service-side activity record.

Conceptual architecture · mobile product in development