Agreebase is designed to leave a sealed record with artifacts that can be retained and checked independently of a later Agreebase session. The permanence profile depends on the record type and publication choices.
What sealing creates
For agreements, declarations, and witnessed agreements, sealing fixes the current body, participant evidence, and version. Agreebase queues:
- A party-facing evidence metadata package.
- A signed PDF, generated asynchronously.
- Confirmation emails and verification links.
- A blockchain write containing a public record.
For notarizations, sealing fixes the content type, content hash, notarization metadata, and signer evidence. Notarizations do not generate signed PDFs; a private PNG card can be generated instead.
What goes to Base
Agreebase writes a zero-value transaction whose calldata contains a human-readable public record. Ordinary records contain the AGR reference, either the body text or body hash, the evidence metadata hash, the completion time, and optional verified party details.
Notarization records contain the AGR reference, content hash, content type, hash algorithm, selected advisory metadata, metadata hash, and completion time. Normalized text is included only when text publication was explicitly enabled.
A hash-only agreement record looks like this; plain, readable text, not binary or ABI-encoded data:
Agreebase.com - AGR-2026-000123
Body hash: sha256:4a1e9c2f7b8d3e015c9a6f2b1d8e4c7a3f9b2e6d1c4a8f5b3e2d9c6a1f7b4e8d
Metadata hash: sha256:9f3b2e7c1a8d4f6b2e9c5a1d7f3b8e4c2a6f9d1b5e8c3a7f4b2d9e6c1a8f5b3e
Completed: 2026-07-20T14:32:11Z
Verified signatory: Jordan Lee (jordan@example.com), 2026-07-20T14:29:03Z
Verified signatory: Priya Shah (priya@example.com), 2026-07-20T14:31:47Z
The "Verified signatory" lines only appear when verified party publication was enabled for that record; a plain hash-only record without that option omits them entirely. This is exactly what you'd see reading the transaction's input data on a block explorer; see Comparing document hashes for how to look one up.
The blockchain is public and permanent. It is an anchoring layer, not a private document vault.
Publication modes
Hash-only publication keeps ordinary record text off chain and publishes a cryptographic commitment. Full-text publication puts the selected text in public blockchain calldata. Verified party publication can include entered names and verified signing email addresses.
Full-text and verified-party publication are independent choices. They are both off by default and cannot be undone after the blockchain transaction confirms. See Privacy before enabling either option.
Independent verification
A verifier with the candidate text or content can recompute the body/content hash. A verifier with the evidence package can recompute the metadata hash. A verifier with the transaction hash can inspect the chain record directly.
The public verifier is the easiest interface, but it is not the only source of evidence. See Comparing document hashes and Verification hashes.
Asynchronous completion
Sealing, PDF generation, document signing, and blockchain writing are separate operations. A sealed response may therefore show a pending document or blockchain state. A later confirmation email can provide the transaction hash, block number, explorer URL, and write time.
What permanence does not mean
Permanence does not mean that the real-world arrangement cannot change, that a statement is true, or that a record is legally enforceable. It means the sealed record and its proof artifacts are designed to remain checkable.
Later amendments, mutual cancellation records, and superseding records preserve the earlier history while making a later record current. They do not rewrite the earlier blockchain commitment.