# TokenTable

## What is TokenTable?

TokenTable is the **capital allocation and distribution engine** of the S.I.G.N. ecosystem.

It is designed to handle **large-scale, rules-driven distributions** of value, including:

* government benefits and subsidies,
* grants and incentive programs,
* tokenized capital and assets,
* ecosystem and protocol distributions,
* regulated airdrops and unlocks.

TokenTable focuses on **who gets what, when, and under which rules**, while delegating **evidence, identity, and verification** to Sign Protocol.

***

## Why TokenTable exists

Traditional distribution systems rely on:

* spreadsheets and manual reconciliation,
* opaque beneficiary lists,
* one-off scripts or centralized payment processors,
* post-hoc audits that are slow and incomplete.

These approaches do not scale and are prone to:

* duplicate payments,
* eligibility fraud,
* operational errors,
* weak accountability.

TokenTable replaces these with **deterministic, auditable, programmatic distributions**.

***

## Core responsibilities

TokenTable is responsible for:

* defining allocation logic,
* executing distributions,
* managing vesting and unlock schedules,
* enforcing eligibility constraints,
* producing deterministic allocation outputs.

It is **not** responsible for identity issuance or cryptographic evidence — those are handled by Sign Protocol.

***

## Key capabilities

### 1) Allocation tables

TokenTable operates on allocation tables that define:

* beneficiary identifiers (DIDs, addresses, or internal references),
* allocation amounts,
* vesting parameters,
* claim conditions,
* revocation and clawback rules.

Allocation tables are versioned and immutable once finalized.

***

### 2) Vesting and unlocks

Supported vesting models include:

* immediate release,
* cliff-based vesting,
* linear vesting,
* custom schedules.

Each vesting schedule is enforced deterministically by the system.

***

### 3) Claim execution

TokenTable supports:

* direct distribution (push),
* beneficiary-initiated claiming (pull),
* delegated claiming (third-party execution),
* batched settlement.

Execution can occur on:

* private CBDC rails,
* public regulated stablecoins,
* public blockchain tokens.

***

### 4) Revocation and clawback

Programs may define:

* revocation conditions,
* partial or full clawbacks,
* emergency freezes,
* expiry windows.

All revocations are versioned and auditable.

***

### 5) Delegation and operators

TokenTable supports operational delegation:

* custodians executing on behalf of beneficiaries,
* government agencies operating sub-programs,
* service providers handling claims.

Delegation is policy-controlled and logged.

***

## Relationship to Sign Protocol

TokenTable integrates tightly with Sign Protocol:

* eligibility proofs are referenced via attestations,
* allocation manifests are anchored as evidence,
* execution results are linked to settlement attestations,
* audits replay allocation logic deterministically.

TokenTable **consumes** Sign Protocol evidence and **produces** new evidence.

***

## Canonical flows

### Flow 1: Welfare or subsidy distribution

1. Eligibility verified via [New ID System](/national-systems/new-id-system.md)
2. Eligibility evidence anchored via [Sign Protocol](/products-sign-ecosystem/sign-protocol.md)
3. Allocation table generated in [TokenTable](/products-sign-ecosystem/tokentable.md)
4. Funds distributed according to rules
5. Allocation + execution evidence published

***

### Flow 2: Grant or incentive program

1. Applications collected and evaluated
2. Scoring and eligibility finalized
3. Allocation table published
4. Vesting schedules enforced
5. Public or restricted audit trail provided

***

### Flow 3: Tokenized capital distribution

1. Define token or asset class
2. Generate allocation table
3. Enforce vesting and unlocks
4. Support secondary compliance checks
5. Anchor final settlement evidence

***

## Example allocation manifest (illustrative)

```
{
  "program_id": "EDUCATION_GRANT_2026",
  "ruleset_version": "v1.2",
  "asset_type": "CBDC",
  "total_budget": "25000000",
  "currency": "CBDC",
  "allocations": [
    {
      "beneficiary_ref": "did:example:citizen:92fa...",
      "amount": "5000",
      "vesting": "immediate",
      "eligibility_ref": "attestation:0xabc123..."
    }
  ],
  "generated_at": "2026-06-01T09:00:00Z"
}
```

***

## Governance and controls

TokenTable supports:

* program-level governance,
* allocation approval workflows,
* ruleset versioning,
* emergency pause and rollback,
* audit and reconciliation tooling.

Governance actions are logged and referenceable.

***

## Security model

* deterministic execution
* role-based permissions
* cryptographic references to eligibility and settlement
* separation of concerns between allocation, evidence, and payment rails

***

## Typical users

* government finance ministries
* welfare and social services agencies
* regulators overseeing distribution programs
* Web3 protocols and ecosystems
* auditors and compliance teams

***

## Where TokenTable fits in S.I.G.N.

TokenTable sits between:

* [**New ID System**](/national-systems/new-id-system.md) (who is eligible),
* [**New Money System**](/national-systems/new-money-system.md) (how value moves),
* [**Sign Protocol**](/products-sign-ecosystem/sign-protocol.md) (what evidence exists).

It ensures capital moves **according to rules**, not discretion.

***

## Where to go next

* Capital architecture: [New Capital System](/national-systems/new-capital-system.md)
* Identity prerequisites: [New ID System](/national-systems/new-id-system.md)
* Evidence layer: [Sign Protocol](/products-sign-ecosystem/sign-protocol.md)
* Money rails: [New Money System](/national-systems/new-money-system.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sign.global/products-sign-ecosystem/tokentable.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.