Time Lock Gives Large Transfers a Waiting Period
You can prepare a transfer on your iPhone and still have Cryptograph refuse to sign it. The amount may exceed the allowance you set earlier. A request to increase that allowance can face a waiting period of its own.
Cryptograph keeps signing material off your iPhone. You review and approve transactions on Apple Watch, where your keys are secured by the Secure Enclave. Time Lock adds a rule you choose in advance: how much may move without waiting, and how long protected actions must wait.
That earlier choice matters when someone is pressing for an immediate transfer. A convincing message, a hurried decision, or a person standing beside you can all put pressure on the same approval gesture. Time Lock gives the watch a reason to refuse a request even when you are willing to press it.
A limit across time
Time Lock has two controls: a delay and an optional spend allowance. The available delays are one, three, and seven days. With protection active, the allowance permits qualifying transfers up to a rolling total measured in US dollars.
The accounting window follows the chosen delay. A three-day policy considers recorded spending within the preceding three days. Closing the app or beginning another transfer does not create a fresh allowance. As older spending leaves the window, capacity becomes available again.
For example, suppose you have a $500 allowance and a three-day delay. A recorded transfer worth $200 leaves $300 available within that window. A subsequent $400 transfer exceeds the remaining allowance, even though it is individually below $500. Dividing that request into several smaller transfers does not create extra capacity in the rolling total.
The dollar figure is an enforcement value based on asset prices. Its equivalent in coins can change with the market. When a transfer needs a price for the check, an unavailable or rejected quote can stop the request. A number displayed elsewhere on the phone does not by itself establish permission to spend.
You can also keep Time Lock active without an immediate spending allowance. In that configuration, value transfers subject to the spending check require the delay. Turning the allowance off makes protection more restrictive; turning Time Lock itself off removes the delay policy after the required wait.
What completing the delay permits
You start a countdown on the watch for protected actions. A larger transfer requires planning around that countdown. Merely leaving a blocked request on screen does not schedule a payment for later.
When the countdown completes without a pending settings change, Time Lock enters a temporary Ready state. That window lasts as long as the configured delay: a one-day delay provides a one-day window, and a three-day delay provides a three-day window. During it, the Time Lock spending restriction is lifted.
The window applies to the wallet and can cover multiple distinct transactions. A successful transfer does not consume it. Rejecting or retrying a request does not extend it. You can close the window early with Lock Now; otherwise it expires and the restriction returns.
This distinction matters when judging the protection. The allowance bounds qualifying immediate spending while Time Lock is enforcing it. An already-open Ready window allows larger movement. The countdown gives you time before that broader authority becomes available, and the window defines how long it remains available.
Every transaction still needs its own watch review and approval. Completing the countdown neither signs a transaction nor sends funds automatically. A prepared transfer may need fresh network information before you return to it, and the request must still satisfy the other signing checks.
Protective settings have their own delay
A spending restriction would offer little resistance if someone could immediately raise its limit. Time Lock therefore delays changes that weaken an established policy.
Shortening the delay, turning Time Lock off, or increasing the immediate allowance creates a pending change. The existing protection continues while the countdown runs. From a locked three-day policy, a request to shorten the delay to one day starts a countdown under the existing three-day setting.
Time Lock uses one shared countdown for protected actions and pending settings. A countdown already in progress is not restarted for each new request. The protection is therefore an elapsed waiting requirement, rather than a promise that every settings edit starts another full interval.
When a countdown applies pending settings, the new settings take effect and the timer returns to Locked. That transition does not also open the reusable Ready window for signing. If the pending change was to turn Time Lock off, the delay policy is then off.
Changes in the other direction take effect immediately. You can lengthen the delay, lower the allowance, or remove the immediate allowance. Initial setup also lets you choose an allowance as part of enabling protection. That setup choice is separate from later increasing an established allowance.
The practical purpose is to preserve a decision you made before pressure arrived. Someone who gains access to the watch settings still encounters the waiting requirement for a weaker policy. The settings screen offers a pending change that you can cancel while it waits.
Approval and permission are separate checks
The watch signs the transaction it showed you. Time Lock adds a policy check to that approval process, alongside the checks that establish what the request contains.
For a native transfer, the watch checks Time Lock before presenting approval controls and again before signing. A request that passed an earlier check can still be refused at the later one. For example, the temporary Ready window may have expired while you were reviewing it.
When the policy blocks a request, the watch presents the reason. Holding the approval gesture does not override that refusal. Preparing a transaction on the phone establishes what you want to request; it does not establish that the watch is currently permitted to sign it.
Value also needs to be understood beyond an immediate transfer amount. An approval can grant another address permission to move tokens later. With Time Lock active outside its Ready window, certain approvals to untrusted spenders and unknown contract calls are blocked by the delay protection.
Separate signing policies can refuse other requests regardless of the timer. Waiting is not a general way to make every rejected signature available. Nor does completing a delay establish that a contract is safe. You still need to understand the authority shown on the watch before approving it.
Time changes the pressure
A demand for an immediate transfer depends on your ability to authorize that transfer immediately. A previously configured allowance can reduce the amount available through the protected signing path. The delay requires the demand to persist across time before larger movement becomes possible.
That interval can give you room to reconsider the destination, verify a story through another channel, or cancel a pending change. In a panic-signing situation, the watch can interrupt the sequence between an alarming message and a large transfer. The interruption comes from your earlier settings, without requiring the wallet to identify the message as fraudulent.
Coercion has a harder boundary. Cryptograph cannot determine whether your approval is freely given. A sustained attacker may wait out the delay. Amounts within the available allowance may still move, and an open Ready window changes the immediate exposure. Time Lock can bound and delay some losses; it cannot guarantee safety under duress.
The policy also governs Cryptograph’s signing path. A BIP39 mnemonic exists, and possession of sufficient recovery material can allow someone to restore signing authority elsewhere. A local wallet delay does not become a restriction enforced by every blockchain or every other wallet. Protecting recovery material remains necessary.
A deliberate interval
Time Lock settings and spending records are held in the watch Keychain as device-only data. The countdown checks elapsed time against both the system clock and a separate monotonic clock. Moving the displayed date forward does not provide the missing elapsed time for a new countdown.
Those mechanisms support a practical choice: keep a defined amount available for ordinary transfers and require advance notice for broader access. The waiting period applies to you as well. A legitimate urgent transfer can encounter the same refusal as a request made under pressure.
The useful policy is one you understand before relying on it: the rolling allowance, the delay, the temporary Ready window, and the settings that are still pending. Together, those controls let an earlier decision remain effective when the next request arrives.
The Cryptograph Team