Why Every Handoff Gets Two Timestamps, Not One
One timestamp when you send, one when everyone has signed. The second is the headline. The first is the one that saves you when the other side refuses to sign at all.
Every Pactbound handoff writes two records to a public ledger. One when you send it, one when the last required person has signed off. The second is the moment the product is named for. The first exists for a scenario the second cannot cover: the other side stalls, or refuses to sign, and you need to prove what you handed over anyway.
Most systems only record the second. That is a problem, and it shows up at exactly the worst time.
The two events
| Anchor | Fires when | What it proves |
|---|---|---|
bundle_created | You hit send, before any sign-off | This content and these disclosures existed and were presented at this time |
bundle_sealed | Every required recipient has acknowledged | The complete record, content plus disclosures plus signatures, was final at this time |
The sealed anchor commits to finalBundleHash, which is the hash of the manifest in its final state. The creation anchor commits to merkleRoot and the bundle hash as they stood at send. A verifier recomputes both from the file's own bytes and matches each against its record, fetched from a public mirror node.
The case the second timestamp cannot cover
Picture an MSP offboarding that has gone sour. You are the departing provider. You have packaged the credentials, the network documentation, and a disclosure saying the backup server has been failing since January. You send it. The client, or the incoming provider, never signs.
Dating a record at the moment it is created is not a new idea. This is a 1964 security poster from a United States defense contractor, printed the same year the stamp in it reads. Photo: hughes aircraft company via Library of Congress. Library of Congress, no known restrictions (verify per item).
With only a finalization timestamp, you have nothing. Nothing was finalized, so nothing was recorded. The strongest thing you can say is that you sent an email.
With the creation timestamp, you can prove that on March 1st at 2:14pm you presented exactly this content, including the warning about the backup server, and that the content has not changed since. Whether they signed is now their problem rather than yours.
That is not a hypothetical edge case. An adversarial offboarding is precisely the situation where a departing provider needs evidence most, and it is the situation where a sign-off will not be forthcoming.
Why not just one anchor after signing
Because the two prove genuinely different things, and collapsing them loses one.
Proof of disclosure and proof of agreement are separate stamps because they answer separate questions. Photo: Markus Spiske via Pexels. Pexels License.
The creation anchor is proof of disclosure: here is what I told you, and when. The sealed anchor is proof of agreement: here is what we settled on, and when. A dispute about whether a warning was ever given is answered by the first. A dispute about what was agreed is answered by the second.
Systems that record only the agreement can answer the second question and are silent on the first.
What it costs
A Hedera Consensus Service message costs $0.0008 at the fixed rate published on Hedera's fee schedule. Two anchors per handoff is $0.0016, and that figure does not move with the number of recipients, because the anchors commit to the bundle rather than to each signature.
At $0.0008 per anchor the cost argument for recording only one of the two events does not exist. Photo: James Sutton via Openverse. CC0 1.0.
At that price the argument for dropping the creation anchor to save money does not exist. The only real argument would be that a one-stamp story is simpler to explain, and we would rather explain two stamps than leave a customer with nothing in the case where the counterparty walks away.
When there are more than two
Two is the default, not the ceiling.
bundle_countersignedfires when the sender counter-signs an already-acknowledged bundlebundle_acknowledgedcan fire per signature, giving each individual sign-off its own on-chain timestamp, and is off by default
Because every acknowledgment changes the manifest, each of these carries a different finalBundleHash. That is not drift. Each anchor is a valid proof of the bundle's state at that consensus time, and a verifier recomputing the bundle as it stands today matches the most recent one.
What the ledger does not tell you
The anchors establish what and when. They do not establish who.
The ledger is precise about when. It is deliberately silent about who, because no personal data goes on chain. Photo: Towfiqu barbhuiya via Pexels. Pexels License.
No personal data goes on chain, deliberately. The message carries hashes and counts, nothing else. Identity comes from the acknowledgment records inside the bundle: the one-time code sent to the signer's email, the recorded consent, the IP, and the timestamp. Those are strong, ordinary evidence of who acted. They are not cryptographic attribution, and we do not describe them as such.
If you want to see how the anchor gets checked step by step, that is covered in verifying a handoff without trusting us.