Ceremony run-through
Form groups, wrap, cut over, and deliver — without Rekey ever holding a clear secret.
Rekey
Rekey helps one group pass control of a digital asset to another — with no single person holding the whole key. The secret is created on participant machines; our service never holds clear KEY or clear file payloads.
Sometimes control of an account or a sealed package needs to move from the people who set it up to another trusted group. Rekey runs that handoff as a guided ceremony.
A short story of the path from setup to the receiving group. Press play, or step through one scene at a time.
Scene 1
Captioned walkthroughs of a Rekey ceremony — first the core handoff, then a TRON Rally ownership transfer.
Form groups, wrap, cut over, and deliver — without Rekey ever holding a clear secret.
Same ceremony path with on-chain Rally ownership appointed to B′ at unload.
Rekey’s cloud service never holds clear KEY, and never receives clear file payloads. Secrets are created on participant machines. Sealed packages stay sealed while they travel through us — the service coordinates; it does not open your sealed mailboxes.
Stage-by-stage custody (who can see what, when) is in the Knowledge by stage FAQ. Terms like KEY, DKG, and sealed mail are under Basics.
We’re inviting a small number of organizers to try Rekey. Leave your email and we’ll follow up with access when a seat opens.
If you already have an invite code, we’ll send install steps with your access email. Enter the code when you create a ceremony.
Plain answers, grouped by topic. Jump to a section, then open a question.
Ceremony shape, the agent, and core crypto terms.
A structured handoff with named seats, invitations, and clear stages (setup → seal → hand over → deliver). Everyone follows the same script so control moves on purpose, not by informal key sharing.
A program you install on your own computer. It holds that seat’s keys, talks to the Rekey service for sealed mail and status, and never uploads your private keys to us.
Group A sets up the handoff and holds early custody. Group B is the receiving group after the handoff. The organizer is usually on the A side and helps run the process — but the organizer is not required to be an A seat.
The secret that can unlock the delivery (for example decrypt a sealed file, or authorize a change on a blockchain account). That secret is split across people, and Rekey’s cloud service never holds it in the clear.
A way for several computers to create a shared secret together so that no one machine ever needs to see the whole secret first. In Rekey’s default path, Group A (plus a special completing piece held by the organizer) creates that secret locally.
An extra share the organizer holds so that Group A alone cannot rebuild the full secret. After handoff, the receiving group gets their own completing piece. Think of it as a required co-signature in share form, not a password we store.
Cutover is the step that moves custody from A toward B. VSR (verifiable secret redistribution) is a method that reshapes the shares for the new group without putting the full secret back together on a single dealer machine along the way.
Ceremony roster and status, sealed packages, and coordination messages. For file deliveries: ciphertext only — never clear payload bytes. For some blockchain deliveries: a public account manifest — never a clear private signing key.
A stage-by-stage custody map for organizers and reviewers. “Group A knows KEY” means a threshold of A seats cooperating (plus the king where required) — not each seat alone.
Columns are who might hold something; rows are what. Open a stage below for that moment in the ceremony. Cells mean: Yes (holds or can derive it), Share (needs quorum to form KEY), Sealed (ciphertext they can open locally, or opaque on our service), Public (intentionally non-secret), No (must not have clear access by design).
| Label | Who |
|---|---|
| Public | Anyone who can read ceremony status, join pages, explorers, or this site. |
| No one (clear) | Bytes may exist as ciphertext, but no listed party can read the clear secret from that alone. |
| SaaS | Rekey’s ceremony service — honest-but-curious coordinator; never meant to hold clear KEY or clear file payload. |
| Organizer | Ceremony operator (local agent). Holds the Act I king escrow after wrap. Not required to be a Group A seat. |
| Group A / B | Act I custodians / receiving custodians after cutover (threshold). |
| Combiner | Designated B seat that collects peer exports and unwraps / unloads. |
| On-chain | TRON observers (Rally address, Owner history, appoint tx). |
| Element | Public | SaaS | Organizer | Groups |
|---|---|---|---|---|
| Ceremony ID, thresholds, product | Yes | Yes | Yes | — |
| Organizer email (OTP-verified) | On join page | Yes | Yes | — |
| Organizer public keys | Yes | Yes | Yes (+ sk locally) | — |
| Organizer private keys | No | No | Yes (seat machine) | No |
| Clear KEY | — | No | No | Not born yet |
| Beta invite code | No | Checks digest | Knows plaintext | No |
| Element | Public | SaaS | Organizer | That seat | Other seats |
|---|---|---|---|---|---|
| Roster emails / party ids | Partial | Yes | Yes | Own email | May see others |
| Join URL | Anyone with the link | Stores | Sends | Uses | No |
| Seat identity private keys | No | No | No | Yes (at claim) | No |
| Email OTP / public card | — | Verifies | Sees flag | Proves email | No |
Invite JSON is not KEY. It binds the seat into the ceremony crypto setup. Release / install URLs are public; invite channel material stays off the public status page.
After DKG, each A seat holds a share; the organizer holds the king share. No single party should learn the full KEY alone — forming it needs an A quorum plus the king.
| Element | Public / SaaS | Organizer | Groups |
|---|---|---|---|
| Clear file (blob product) | Never on SaaS | Yes at wrap input | No |
| Sealed file ciphertext | On SaaS (opaque) | Had clear at wrap | Need KEY to open |
| TRON Rally manifest / address | Public | Publishes | Can read meta |
| Act I king escrow | No | Yes (sealed locally) | No |
Organizer with only the king escrow is still not the full KEY.
Release authorization and signatures become public on status as they collect. Clear KEY / PAY are unchanged from wrap: king escrow on the organizer; shares only on seats.
Cutover flags are public. B receives sealed mailbox packages (B-epoch share + B king). VSR must not reconstruct the full KEY on the organizer. Act I king escrow stays with the organizer until delivery latch or scrub. B still needs a B quorum (plus king) before they can open PAY.
Each B seat opens their own share locally. The combiner collects peer exports and reconstructs clear KEY in memory / local state — SaaS never sees it. Clear file PAY (blob) or TRON appoint capability appears only on that unload path.
| Element | Public / chain | Combiner | Others |
|---|---|---|---|
| Delivered file bytes | No | Yes | No |
| Appoint tx / new Owner | Yes | Yes | Can observe |
| B′ address | Yes | Yes | Yes |
| B′ secret key | No | Yes (local sealed) | No |
| Delivery hash | Once published | Computes | B cosigns |
A Group B quorum signs the delivery hash. Then delivery is latched complete and reclaim-to-A is blocked. The organizer’s Act I king is scrubbed on the happy path.
Until delivery wins, attested reclaim can restore Act I king + A shares to A mailboxes. After reclaim, treat KEY as potentially still held by B — rekey / rotate. Reclaim does not fully claw back B-epoch material B already opened.
| Situation | Clear blob PAY / usable Rally control |
|---|---|
| After wrap, before cutover | A quorum + king (organizer supplies king). SaaS: never. |
| After cutover, before B unwrap | B quorum + B-epoch king. A blocked without reclaim. |
| After B unload (blob) | Combiner machine has clear file; SaaS still only ciphertext. |
| After TRON appoint | On-chain Owner = B′; B′ key on unload machine. Rally address public. |
| After delivery latch | Reclaim to A refused; Act I king scrubbed. |
| After reclaim without rekey | A can form KEY again; B may still hold B-epoch material. |
Access, email, and what we never hold.
Creating live ceremonies on our hosted service is invite-only during beta, so we can support participants carefully. Starting a production ceremony needs the invite code we send after approval.
That address is used as the from line on automated invite and verification email. It is not a monitored inbox for human replies — use the beta form on this page instead.
No. The hosted service never holds clear KEY and never receives clear file payloads. You run the agent; sealed material opens on participant machines.
These apply when the delivery is a TRON Rally account (not a sealed file). A design goal is unlinkability: outsiders should not learn Group B’s real-world identity, or tie those people to who can move Rally.
The ceremony creates a new Rally address from the group’s shared public key — not by importing an existing wallet. That address is the on-chain account whose Owner permission is what you hand off. Rekey’s cloud service never holds a Rally private key for the threshold products.
Optional. Leave it off to seal the new Rally address without touching the chain (you can fund later). Turn it on only if the organizer’s machine can pay network fees from an operator funder wallet: Wrap then activates Rally on Shasta, tops it up with a fee reserve (about 100 TRX for a later ownership update), and finishes threshold on-chain setup. You can also optionally leave extra TRX on Rally, or reserve about 2 TRX so B′ can be activated later from Rally instead of a separate funder→B′ transfer. That does not import an old account — each ceremony still derives a fresh Rally.
B′ is a fresh TRON key created at delivery (usually on the receiving group’s combiner machine). Appoint is a single on-chain permission update: Rally’s Owner becomes B′. That costs about 100 TRX from Rally’s balance (the reserve funded earlier). After appoint, control of Rally is the B′ private key — not the ceremony’s shared signing group. The private key stays sealed on the machine that ran appoint; it cannot be rebuilt from the address alone.
No. Activating B′ only gives B′ itself an on-chain presence. Rally can already receive TRX and, after appoint, be spent with the B′ key even if B′ was never funded. Anyone can add TRX to an active Rally; spending Rally’s balance requires the current Owner key (B′ after appoint). Activating B′ is separate from moving or spending Rally funds.
Ceremony participants (organizer and seats) know Group B’s contact identities by design. The wider world should not learn those people’s names or emails from the chain, and should not be able to prove “this Rally is controlled by that group.” After appoint, explorers show Rally’s Owner as a TRON address (B′). Privacy here means unlinkability: that Owner is a fresh key, not a known wallet belonging to a named person — not that ownership is invisible on-chain.
Leave B′ inactive (preferred for privacy). B′ never receives TRX, so it often does not appear as its own funded account on explorers. Rally still works as a transfer account: it can be topped up and spent with the B′ key. Outsiders who look up Rally may see an Owner address, but B′ itself stays quiet — no separate B′ balance history, and no “B′ was funded from X” trail. This is the stealthed controller pattern.
Activate B′. B′ becomes a visible on-chain account (explorer presence, its own balance). That helps public validation and using B′ as a normal wallet, but it increases visibility. Funding B′ from a known operator wallet can also create a linkable chain trail to B′. Use activation when you want B′ obvious; skip it when you want the final controller to stay as quiet as the chain allows.
The unload machine (usually the Group B combiner) creates and holds the B′ private key. Ceremony participants may learn the B′ address at delivery. Rekey’s service must never hold that private key. Control of Rally after appoint is whoever has the B′ key — not whoever merely sees the address. A later ownership change is another permission update signed by the current Owner (again needing Rally fee balance), still without requiring B′ to have been activated.