Single key
A single key can be a single point of failure.
One key controls everything. If it is lost, destroyed, or held by someone who can no longer use it, assets may stay frozen on-chain forever.
A safety net for self-custody
Choose your recovery recipient and set your check-in schedule. If you miss your deadline, CKB enforces the recovery rules you put in place.

The missing layer
Most recovery options ask you to choose between doing everything alone and trusting someone else with your assets. Tranfr offers a different path.
Single key
One key controls everything. If it is lost, destroyed, or held by someone who can no longer use it, assets may stay frozen on-chain forever.
Multisig & custodians
Multisig can add coordination for daily use. Custodians and third-party services introduce people, processes, and delays.
Tranfr safety net
One owner key during normal life. If you go quiet past a deadline you set, a trusted recipient has a defined recovery path.
Simple by design
Three clear steps. Your assets stay in your control until the recovery window opens.
Explore the interactive sandboxStep 01
Choose a trusted recipient and set an inactivity window that feels right for you.
Your assets stay under your own control. The policy only defines what happens if the deadline passes without a heartbeat.
Step 02
Check in whenever you like to restart the countdown.
A heartbeat proves you are still active and resets the deadline. You can check in at any time — there is no fixed schedule to keep.
Step 03
When the deadline passes, your recipient can follow the recovery path you set.
The on-chain rules determine when recovery is available. No custodian holds your funds or decides whether the deadline has passed.
Transparent rules
A deterministic state machine, enforced by each chain's own scripting layer. No central operator, no hidden switch.
The owner creates a Tranfr policy with a recipient and a recovery window. Assets remain under owner control until the deadline.
While active, the owner sends periodic heartbeats to reset the deadline. Each action renews their time to be around.
If no heartbeat arrives before the deadline, the owner path freezes. The inactivity threshold cannot be reset.
The recipient submits a recovery transaction. The chain validates the deadline and the recipient lock before releasing the assets.
CKB-style local simulator
Test the policy states, timing, and recovery path. Everything here is a local simulation — no wallet connection, chain data, or transactions.
Confirm the owner is active and reset the inactivity timer.
Simulate a normal owner action while the policy is active.
Simulation ready. No wallet is connected and no transaction will be sent.
Built around verifiable rules
No custodians. No central oracles. Just a designated path executed on-chain. The policy makes the owner, recipient, and timing conditions explicit.
Policy structure
Representative fields in a recovery policy:
On-chain invariants
The state machine is designed to enforce:
The owner keeps control before the deadline.
The recovery window cannot be reset after expiry.
Only the designated recipient can complete recovery.
For builders
Add heartbeat-based recovery to your own wallet or app.
Clear answers about the recovery path and what stays in your hands.
Once the deadline passes, your owner path freezes and your recovery recipient can claim the assets. Choose a period you can comfortably beat.
You set it in days. A longer period gives you more room if you're offline, but your recipient waits longer if something happens to you.
Yes, any time before the deadline. Updating the recipient also resets the timer.
No. You keep full spend and policy authority until the deadline, and no third party holds your funds.
It's designed to, with CKB as the reference implementation today.