# Data handling

> Product-level facts about what Agreebase receives, stores, exposes, and publishes for records and signing.

Audiences: users, developers, agents
Kind: policy
Updated: 2026-07-12

This page describes current product behavior in plain terms: what Agreebase receives, stores, and exposes as you create, sign, and verify records. It is not a complete legal privacy notice; it doesn't define jurisdiction-specific rights, retention periods, subprocessors, or legal bases. Where this page and an authoritative privacy notice differ, the privacy notice governs.

## What you give Agreebase, by record type

**Agreements, declarations, and witnessed agreements**: the record body text you write is stored in full, so it can be shown back to participants and included in the signed PDF and evidence metadata after sealing. It is not written to the public blockchain by default; only a hash of it is, unless the initiator explicitly turns on full-text publication.

**File notarizations**: your browser hashes the file locally and sends Agreebase only the resulting digest plus whatever advisory label, size, or MIME type you provide. The file itself, its local path, its timestamps, and any EXIF or embedded metadata never reach Agreebase.

**Text notarizations**: unlike file notarizations, Agreebase does receive the actual text here, because it has to normalize it and check the submitted hash against that normalization. That text is kept private by default and only appears in a public record if you explicitly enable public text publication for that notarization.

**Contact details**: names and email addresses (or other contact points, for methods like Telegram) you enter for yourself and for people you invite are stored so Agreebase can send invitations, run authentication, and build signature evidence. These are ordinary stored values internally, not hashed at rest, but anything Agreebase exposes back out (party-facing evidence packages, public verification responses) uses redacted values and scoped one-way HMAC hashes instead of the raw contact details.

## What signing evidence looks like

When someone completes a signature method, Agreebase records which method was used, when, through what channel, and, for public proof-post methods, the URL, handle, and post/gist identifier that were checked. It also records a hashed representation of network context (IP address and user-agent are one-way hashed, not stored in the clear) plus coarse-grained country and device type. Raw OTP codes are never stored in plaintext, only their hash, and public verification never returns any of this evidence directly; see [Privacy and publication](/docs/concepts/privacy) for what a public verification response can and can't reveal.

## What becomes public, and when

The default blockchain write for an ordinary record contains only the AGR reference, a body hash, an evidence-metadata hash, and a completion time; not the text and not participant details. Three things can make more public, and each is an explicit, separate opt-in at creation time: full-text publication, public text for a notarization, and verified-party publication (which can add entered names and verified signing emails to the chain record). None of these are reversible once the transaction confirms; a blockchain write cannot be edited or taken back, by Agreebase or anyone else, regardless of what happens to the Agreebase record afterward.

Public proof-post methods (GitHub, X, Reddit) also make a proof post visible on that external platform for as long as it stays up; see [Privacy and publication](/docs/concepts/privacy#public-proof-methods) for what that proof contains and when it's safe to remove.

## What rescinding, cancelling, or superseding does not do

Ending a pending record, cancelling a draft, or superseding a sealed record with an amendment changes what Agreebase's own systems consider current; it does not reach back and unpublish anything already written to the blockchain, and it does not delete the earlier record's history. Do not treat any of these actions as a deletion guarantee for data that has already gone on chain.

## Where to go for anything this page doesn't cover

Retention schedules, data subject access/correction/erasure requests, cross-border transfer terms, and the list of subprocessors are governed by Agreebase's authoritative privacy notice and support channels where available, not by this page. If you need a decision on one of those questions for a specific record or account, that's the right place to ask.