A Pactbound receipt is verifiable by anyone, with nothing reliant on us.
That’s the whole point of a sealed sign-off: someone outside the argument (a small-claims judge, a chargeback arbitrator, an insurance adjuster) can pick it up, confirm it’s genuine on their own, and weigh it as fact. This page explains exactly how, and where the limits are.
Whether any record is accepted in a specific proceeding depends on your jurisdiction and the facts of your case. Pactbound is a documentation tool, not a law firm, and this page is not legal advice. See our Terms.
Court admissibility: small claims and beyond.
US federal law (the E-SIGN Act, 15 U.S.C. § 7001) and state law (the Uniform Electronic Transactions Act, adopted in 49 states plus the District of Columbia; New York has its own Electronic Signatures and Records Act with parallel effect) provide that an electronic record or signature may not be denied legal effect, validity, or enforceability solely because it is in electronic form. Whether a specific record is actually accepted in a given proceeding still depends on the standard authentication rules, most relevantly Federal Rule of Evidence 902(13) and (14), which cover self-authentication of records generated by an electronic process and data copied from an electronic device. Pactbound bundles are built to satisfy those rules through four elements:
Authentication
Pactbound records the verified email, timestamp, IP address, and user agent for every acknowledgment. These are the kinds of indicia a court evaluates under FRE 901 when establishing who created or assented to a record.
Content integrity
Every file is hashed with SHA-256 (a NIST-standard hash function specified in FIPS PUB 180-4) and the hashes are combined into a Merkle tree. Any change to any byte breaks the chain.
Independent timestamp
Bundles are timestamped externally on a public ledger Pactbound does not control. The timestamp can be independently confirmed years later: meaning we cannot backdate, alter, or invalidate the record.
Audit trail
Every view, every acknowledgment, every change request is logged with timestamp and actor. The audit trail is exportable as PDF and CSV.
Most disputes between a provider and a client (or a departing client and the firm that took over) settle long before trial: through demand letters, mediation, or small-claims filings. Pactbound is built so the receipt does the heavy lifting at that stage. If your demand letter includes a sealed acknowledgment from the named party with a verifiable external timestamp, you almost never get to court. That’s the point.
Stripe chargeback & card-network dispute evidence.
If your client paid by card and filed a chargeback claiming “services not provided as described,” you have a limited window to submit evidence. Stripe’s own dispute evidence documentation specifies what wins: proof of delivery, proof of customer acceptance, signed contracts or service agreements, and a clear description of what was provided.
A Pactbound bundle is structured to provide all three in one artifact:
Proof of delivery
For offline services, Stripe's evidence guidance specifically asks for documentation showing the service was provided, including the date the cardholder received or began receiving it. A Pactbound bundle's sealed deliverables and SHA-256 hashes satisfy that artifact requirement.
Customer communication / acknowledgment
Stripe asks senders to show whether the customer communicated about the issue before filing the dispute. Pactbound's identity-verified email-OTP acknowledgment is exactly that kind of contemporaneous, recorded customer communication: submittable directly into the dispute response.
Contract trail
The SOW and every change request can be included in the same bundle, sealed and acknowledged at the time of agreement: not reconstructed from email after the dispute. Useful background evidence under Stripe's customer-details and product-details sections.
The bundle is exportable as PDF and uploadable directly to Stripe’s dispute interface, or to Square, PayPal, Adyen, any processor with a structured evidence form.
E&O / professional indemnity insurance claims.
When a client makes an Errors & Omissions or professional indemnity claim against you, your carrier’s investigation asks the same questions every time: what was the scope, what was delivered, did the client accept it? Carriers want clean, structured, contemporaneously-recorded evidence, not Slack screenshots reconstructed after the fact.
Evidence of scope
The SOW + disclosures + agreed-on assumptions are part of the sealed bundle. Whatever you said was in or out of scope is on the record.
Evidence of delivery
The deliverable files are hashed and sealed. The carrier can verify exactly what was sent, when, and to whom.
Evidence of acceptance
Identity-verified acknowledgment from the named project sponsor. The carrier sees the client agreed before the dispute arose.
Carriers we’ve spoken with (informally, this is not legal advice) treat well-organized, contemporaneous, identity-verified evidence as the gold standard for substantiating that you performed the work as agreed. Pactbound is purpose-built to produce exactly that artifact.
The receipt outlives Pactbound.
Every other sign-off tool (DocuSign, HoneyBook, PandaDoc) stores the audit log on their servers. If they go away, your evidence becomes a PDF whose chain of custody lives in a vendor database you no longer have access to. Most of the time, that’s fine. For disputes that surface two or five years post-delivery, it’s an open question.
Pactbound bundles are different in one specific way: the timestamp is anchored externally on a public ledger that exists independently of our company. Any third party (your client’s lawyer, an arbitrator, an adjuster) can verify the receipt’s authenticity using our open-source script without touching our servers. If Pactbound goes away tomorrow, your receipts still hold up.
For the technical reader curious about the specific anchoring mechanism (the Hedera Consensus Service) and how it compares to alternatives (RFC 3161, OpenTimestamps, DocuSign’s CA), see the technical comparison page. For everyone else: the receipt works without us, that’s the point.
Verifiable by anyone: including your client’s lawyer.
The verifier is a small, open-source script that takes a Pactbound bundle and confirms, without contacting our servers, that every file hash matches, the Merkle root is internally consistent, the external timestamp anchor checks out, and the acknowledgment signatures are valid.
$ node scripts/verify-bundle.mjs path/to/bundle.pactbound --check-onchainAnyone can run it. The verifier is roughly 200 lines of code. If our software disagrees with the verifier about whether a bundle is authentic, trust the verifier. That’s what makes a Pactbound receipt hard to dismiss: the math is auditable by the same opposing-counsel forensics expert who would otherwise tear apart a Slack screenshot. Whether it’s admitted is still the court’s call; what you bring is an artifact built to survive that scrutiny.
Receipts that hold up. So you’re covered.
Try it on your next handoff or sign-off. Your first five are free. No card.