Compute
Encrypted checkpoints for Covenant Compute.
Save a checkpoint before closing your GPU lease. Restore the same file for your next lease. Your client encrypts the snapshot, and you retain the key.
Save a checkpoint. Restore the exact version.
01
Save
Your client encrypts a local file and uploads the ciphertext directly to private object storage. Archive a directory first to capture its files in one snapshot.
02
Commit
Covenant checks the stored ciphertext’s size and SHA-256 digest before advancing the workspace version. The client retains the version it accepted.
03
Restore
Your client requests its pinned snapshot, checks the ciphertext and decrypts it locally. Transfer the recovered file to the next lease through an authenticated SSH connection.
From one lease to the next
Use the same buyer identity and coordinator endpoint throughout. Copy the checkpoint from your source lease to your client before saving it. Each save captures a file at that moment; subsequent changes need another save.
# Installs the checksum-pinned Compute 0.3.0 release for macOS or Linux.
curl -fsSL https://opencovenant.org/install/compute.sh | sh
export PATH="$HOME/.local/bin:$PATH"
export COVENANT_COMPUTE_COORDINATOR_URL=https://compute-api.opencovenant.org# Use your existing buyer identity and accepted coordinator endpoint.
# Copy checkpoint files from the source lease through authenticated SSH,
# then archive the directory locally before saving it.
tar -cf checkpoint.tar -C ./checkpoint-files .
# Save the workspace UUID. Reuse it for every command below.
covenant-compute workspace create training-checkpoint --id <workspace-uuid>
covenant-compute workspace save <workspace-uuid> checkpoint.tar
covenant-compute workspace status <workspace-uuid>
# An uncertain upload or commit keeps its original ciphertext and identity.
covenant-compute workspace retry <workspace-uuid>An interrupted operation retains its ciphertext and upload identity. Use workspace retry to resolve that operation before saving another version. Keep the client’s workspace state directory so its key, version pin and pending operation survive a restart.
# The destination file must not already exist.
# --lease checks ownership, the live paid window and the workspace trust floor.
covenant-compute workspace restore <workspace-uuid> restored.tar \
--lease <later-lease-uuid>
# Compare archive digests before transferring the restored file.
shasum -a 256 checkpoint.tar restored.tar
# Transfer restored.tar to the later lease through authenticated SSH.
# The restore command itself writes the file to your local client.The --lease option authorizes a live lease owned by the same buyer and checks its trust level. The restored archive is created on your client; file transfer and unpacking on the rented machine are separate steps under your control.
Saving or restoring a snapshot does not create a rental or transfer funds. GPU leases retain their existing prices, settlement and close procedures.
Release evidence
A synthetic checkpoint was created on an NVIDIA L40S lease, copied to the client, encrypted and saved. After that lease closed, the client restored the archive and transferred it to a second rented instance. Its SHA-256 digest matched exactly. Both instances used the same physical L40S host.
A separate recovery test interrupted the released client during save, then committed the original ciphertext and upload identity after restart. Both leases settled on Solana, their rented instances were removed, and cleanup replaced the stored ciphertext with verified empty markers. These tests establish file persistence and recovery; they do not demonstrate a resumed training run or hardware attestation.
- Verified
- 18 Oct 2026 · 22:47 UTC
- Storage
- Cloudflare R2
- Source lease
- 64b6d628-396e-40cc-bd3c-169146348ec8
- Later lease
- e356d88c-88d6-4320-b9a7-a0bdaf013605
- Archive SHA-256
- 5be69dd8664560c210e9a629b18fb73d5de501e5f8ee2be0188af78978ce50eb
- Ciphertext SHA-256
- 036fedf977fd837c95156449609d0a0c580b2595b5731678ad9a323b1cccb524
Encryption, ownership and version checks
The key stays with your client
Snapshots use authenticated encryption. The coordinator and object store receive ciphertext and metadata. Keep a private backup of the key; Covenant cannot reconstruct a lost key.
The buyer authorizes access
Workspace requests are signed by the owner. Short-lived storage grants cover a specific operation. A lease restore also checks ownership, its remaining paid window and whether closing has begun.
Your client pins the saved version
Restore checks the exact snapshot your client accepted. A different version or digest is refused, and an existing destination file is preserved. Older backups cannot replace a newer local version pin.
Hardware trust is checked separately
Current lease hardware qualifies only for the open trust level. A workspace with a stronger requirement can be recovered locally by its owner; release to lease hardware requires verified evidence that satisfies that requirement.
Keep a private backup
The workspace backup contains its encryption key and exact version pin. Store it privately, separately from the rented machine. Restore it on a client using the same buyer identity and coordinator endpoint.
# This private backup contains the encryption key and exact version pin.
covenant-compute workspace backup <workspace-uuid> private-backup.json
# On another client with the same buyer identity and coordinator endpoint:
covenant-compute workspace import private-backup.json
# Delete the workspace when it is no longer needed.
covenant-compute workspace delete <workspace-uuid>Deletion stops new workspace access. After outstanding grants expire, cleanup replaces the stored ciphertext with an empty marker that prevents a delayed upload from recreating it. The marker is retained. Expired uploads and replaced snapshots follow the same cleanup process.
A previously issued ciphertext URL can remain usable until it expires. Deletion does not erase files or private backups already saved on your own machines.
Snapshot limits
- Snapshot
- One file per saved version; archive directories before saving
- Current capacity
- 1 GiB shared across the deployment, including ciphertext overhead, pending uploads and unconfirmed cleanup
- Object quota
- 4,096 lifetime object allocations across the deployment, including retained cleanup markers; retries reuse their allocation
- Versions
- Restore the latest committed snapshot pinned by your client
- Transfer
- Client-managed copying over authenticated SSH