# 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](https://docs.sign.global/national-systems/new-id-system)
2. Eligibility evidence anchored via [Sign Protocol](https://docs.sign.global/products-sign-ecosystem/sign-protocol)
3. Allocation table generated in [TokenTable](https://docs.sign.global/products-sign-ecosystem/tokentable)
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**](https://docs.sign.global/national-systems/new-id-system) (who is eligible),
* [**New Money System**](https://docs.sign.global/national-systems/new-money-system) (how value moves),
* [**Sign Protocol**](https://docs.sign.global/products-sign-ecosystem/sign-protocol) (what evidence exists).

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

***

## Where to go next

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