# Signing methods

> How Agreebase proof-of-control methods work, what they capture, and what they do not prove.

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

Agreebase signatures are evidence of an explicit signing action and control of a contact point, account, or credential for a specific current record version. They are not merely typed names.

## Available methods

### Email OTP

Agreebase sends a short-lived one-time code to the signing email address. The signer enters the code in the signature method flow. This is the required baseline method.

### GitHub gist

Agreebase generates proof text. The signer publishes it in a public GitHub gist and submits the URL. Agreebase checks the public evidence and records the URL, handle, post/gist identifier, proof hash, and applicable account-age rule.

### X post

The signer publishes generated proof text in a public X post and submits the URL. Availability and provider verification depend on configuration and the external platform.

### Reddit post

The signer creates a public Reddit profile post using the generated title and proof text, then submits the URL. The generated title must be preserved exactly when the workflow requires it.

### Telegram

Agreebase generates a Telegram deep link and challenge. Opening the link in the Agreebase bot proves control of the Telegram chat that completed the challenge. Telegram is a signing channel, not a record-creation channel.

### Passkey

The browser performs a WebAuthn ceremony for the Agreebase relying-party domain. The signer proves control of the passkey-bound private key. The browser-native prompt happens outside a text-only agent conversation.

## Required method count

The creator chooses one, two, or three distinct methods per signer:

- One: email OTP.
- Two: email OTP plus one additional method.
- Three: email OTP plus two additional methods.

The count applies to the current record configuration and to participants who must complete signature execution, including witnesses. An unwitnessed declaration uses one required method.

## Signature execution states

Each method can be available, started, awaiting input, verified, cancelled, or expired. The signature execution response tells an integration whether a method can start, submit, refresh, cancel, or finalize. A signature execution is finalized only when the required distinct methods are verified.

Every method is tied to an agreement reference and version. If a body change creates a new version, prior signature execution is not assent to the new text.

## Evidence captured

Party-facing evidence includes completed method count, finalization time, channel, method names, redacted/scoped contact evidence, public proof URLs, public handles, post identifiers, proof hashes, Telegram chat evidence, and passkey ceremony identifiers. Network evidence is represented with hashed IP and user-agent values plus country and device type.

The evidence package excludes pending or incomplete participants and raw OTP codes. Public verification does not expose the private evidence payload.

## What methods do not prove

Signing methods do not independently prove that the underlying arrangement is legally enforceable, that every statement is true, or that the signer had legal capacity or authority in every context. The narrower claim is that the signer completed the recorded proof steps for the exact version before sealing.