# Start here

> A short orientation to Agreebase record types, signatures, sealing, permanence, and verification.

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

Agreebase turns an agreement, declaration, witnessed record, or content hash into a record that can be checked later. It combines a defined record state, proof-of-control signing methods, privacy choices, and cryptographic commitments.

## Core ideas

An Agreebase record is built around five ideas:

- The text should be understandable by the people signing it.
- Each signing party proves control of an approved contact point or account; "proof-of-control" of an existing digital identity is core to Agreebase's signature.
- The record keeps its lifecycle and version history explicit.
- Once everyone required has signed, the record seals.
- A sealed record can be verified later either via Agreebase or directly on the Base blockchain record.

## Main record types

An agreement is shared text confirmed by two or more signing parties. A declaration is a single-party statement. A witnessed agreement adds witnesses who sign after the main parties. A notarization records a client-supplied SHA-256 hash for a file, text, or existing digest; Agreebase does not receive the source file bytes.

## What gets produced

When an agreement, declaration, or witnessed agreement seals, Agreebase queues confirmation emails, a signed PDF, evidence metadata, and a blockchain write. Notarizations use their notarization payload and private card instead of a signed PDF. Blockchain confirmation generally happens very quickly, but in some cases may follow receipt of the confirmation email by a few seconds or minutes.

## Good first paths

Use the web app for the guided creation and signing experience. Use REST when another system needs a direct HTTP contract. Use MCP when an agent is working with a human in the loop. Use the public verifier when you only need to check an existing record.