Genesis Statement Fide ID

The Genesis Statement pattern is designed to provide stable identity (no "flicker") while remaining decentralized.

Instead of picking a random hash like MIN(), it mints a Primary Fide ID (did:fide:0x10...) derived from the very first statement ever made about an entity.

This ID becomes the anchor for the entire cluster.

Algorithm

Find the "First Seen" Event

Scan the history of an entity cluster. Find the statement with the earliest timestamp (according to the indexer's sync order or trusted timestamp).

Derive the Genesis ID

Calculate the Fide ID for that genesis statement: did:fide:0x00....

Mint the Primary Fide ID

Create the Primary Fide ID by changing the prefix:

did:fide:0x00... (Genesis Statement ID)
did:fide:0x10... (Person Primary Fide ID derived from Genesis Statement)

Link Aliases

All other aliases (x.com/alice, wallet:0x123) point to this Primary Fide ID via owl:sameAs.

SQL Implementation

This query implements the Genesis Statement logic using window functions to find the "First" statement.

-- 1. Identify valid Genesis Events (Subject Statements)
WITH potential_genesis AS (
    SELECT 
        subject_fingerprint,
        statement_fingerprint,
        indexed_at -- Or verified_at for trusted timestamps
    FROM fcp_statements
    WHERE subject_fingerprint IS NOT NULL
),

-- 2. Find the Primary Genesis for each Cluster
cluster_genesis AS (
    SELECT 
        pg.subject_fingerprint,
        pg.statement_fingerprint as genesis_id,
        ROW_NUMBER() OVER (
            PARTITION BY pg.subject_fingerprint 
            ORDER BY pg.indexed_at ASC, pg.statement_fingerprint ASC -- Tie-break with ID
        ) as rank
    FROM potential_genesis pg
)

-- 3. Select the Earliest Statement per Entity
SELECT 
    subject_fingerprint,
    genesis_id
FROM cluster_genesis
WHERE rank = 1;

-- 4. Derive Protocol-Native Primary
-- In application logic: '0x00...' -> '0x10...' (or 20, 30, etc based on type)

Risks & Considerations

In a decentralized network, different indexers may see different "first" statements, leading to ID Divergence.

Race Conditions

If two indexers ingest different statements as "first" (e.g., due to network latency or disparate sync intervals), they will mint different Primary Fide IDs for the same entity.

This requires later reconciliation (merging IDs), which is complex and can break downstream references. This pattern is best used in single-indexer or tightly synchronized environments.