Arbitration and disputes

If a conversation must serve as proof of a deal, exports can be validated offline using public keys and signed commitments.

Evidence workflow

Court dispute example (A vs B)

Scenario

User A and User B agree on terms in a Core51 chat. Later, User B violates the agreement. User A wants to prove in court what was originally agreed. User B claims the messages were fabricated or altered.

What Core51 can provide

  • Authorship proof: messages are digitally signed by the sender’s signing key (Ed25519).
  • Immutability: any modification breaks signature and hash verification.
  • Continuity: messages are linked by a hash chain; removing or reordering breaks the chain.
  • Key continuity signals: key rotations can be detected and surfaced as part of the proof context.

Actions — User A

  1. Export an Evidence Pack for the relevant chat and time period (include context before/after the disputed messages).
  2. Provide the Evidence Pack to counsel / an independent expert for verification.
  3. Optionally provide a human‑readable summary together with the raw cryptographic package.

Actions — Independent verifier / expert

  1. Verify each message signature using the sender’s public signing key.
  2. Verify hash chain continuity for the exported segment.
  3. Produce a short report: which messages are valid, where (if anywhere) the chain breaks, and which keys were used.

Typical defenses — User B

  • “I never wrote this”: if the signature verifies under B’s public key, the message was produced by the holder of that key.
  • “My account/device was compromised”: key rotation history and device/account events help establish timelines.
  • “Messages were edited”: edits would break signature/hash verification unless re‑signed.
Informational only, not legal advice. Courts may require expert testimony to interpret cryptographic verification results.

Core51 treats audit readiness as a product feature, not a manual process. When a conversation matters, you should be able to export it into a proof package that a third party can validate offline. Core51 is designed around signatures and commitments that bind participants to the content they sent, plus integrity chain state that helps detect reordering and omission in the supported model. In practice, this means an organization can respond to an incident with a consistent playbook: export the relevant conversation, provide the key fingerprints and rotation context, and let an independent verifier validate the bundle. This reduces reliance on server trust and increases credibility with auditors, arbitrators, and counterparties. Most teams hope they never need this. But when a deal fails or a conflict escalates, having verifiable records saves time, reduces risk, and prevents costly arguments about what was actually agreed.

Evidence-ready exports

Export a conversation into a portable bundle for auditors, arbitrators, or legal review. Exports are designed to be checkable offline.

Commitments and signatures

Messages can include signed commitments to plaintext (for example, a hash of canonicalized content). This enables later verification without exposing keys.

Chain integrity

Rolling integrity state (hash chain) provides an additional signal to detect reordering, deletion, or insertion attempts within the supported threat model.

Dispute workflow

If something goes off-plan, the organization can produce a proof package and a verifier can validate: signatures, key fingerprints, and integrity chain state.

Preparation for audits

Audit preparation becomes a product feature: consistent identity, key continuity, explicit rotation logs, and a deterministic export format that can be archived.

Open source verifier

A verifier tool will be published to validate exports independently. This reduces reliance on the server and helps third parties confirm integrity.

Core51 app screenshot
Screenshot placeholder. Replace with a real app screen.