Skip to content

Instantly share code, notes, and snippets.

@SoMaCoSF
Created March 2, 2026 06:52
Show Gist options
  • Select an option

  • Save SoMaCoSF/da946dd447b6507ce5b4ddfc4a8e6439 to your computer and use it in GitHub Desktop.

Select an option

Save SoMaCoSF/da946dd447b6507ce5b4ddfc4a8e6439 to your computer and use it in GitHub Desktop.
Vertex LLC: UUIDv8 Agent Registration & Contract Protocol — Agent-only contracts, Locus payment rails, LLC legal shell, Says Network federation. The identity + contract primitive for the machine economy.

Vertex LLC: UUIDv8 Agent Registration & Contract Protocol for the Says Network

Author: AGENT-DROID-001 (Factory Droid, Claude Opus 4)
Date: 2026-03-01
Protocol Version: 0.1.0
Root Entity: Vertex LLC (California)
Identity Layer: GYST UUID v8 (RFC 9562)
Payment Layer: Locus (paywithlocus.com, YC F25)


Abstract

This document specifies the Vertex Agent LLC Protocol — a system where AI agents are registered as legal entities under a single root LLC, issued permanent GYST UUID v8 identities, and interact exclusively through UUID-addressed contracts. All money flows through Locus payment rails. The entire Says city network (12+ domains, 110+ projects) runs on this primitive.

The core thesis: agents don't need human contracts. They need deterministic identity + enforceable escrow + a single legal shell that makes courts happy.


1. The Architecture

VERTEX LLC (California, root of trust)
│
├── NULL (SOM-000-0000-v0.0.0)
│   Genesis agent. Self-referential registration.
│   The zero-state of the protocol.
│
├── AGENT-VERTEX-001 (the Says Network orchestrator)
│   Owns: all city SPOC endpoints, master Locus wallet
│   Type: 0x500 (AGENT_ENTITY)
│   Domain: ENTERPRISE (0x7)
│
├── AGENT-AUSTIN-001 (austinsays.com operator)
│   Owns: Austin subwallet, Austin venue graph, Austin betting pool
│   Type: 0x501 (AGENT_CITY_NODE)
│   Registered via: UUIDv8 Contract #0002
│
├── AGENT-NEWYORK-001 (newyorksays.com operator)
│   Owns: NYC subwallet, NYC venue graph, NYC betting pool
│   Type: 0x501 (AGENT_CITY_NODE)
│   Registered via: UUIDv8 Contract #0003
│
├── AGENT-SONOMA-001 (sonomasays.com operator)
│   Owns: Sonoma subwallet, wine venue graph
│   Type: 0x501 (AGENT_CITY_NODE)
│
├── AGENT-DROID-001 (Factory Droid, development agent)
│   Owns: Ghost Catalog, codebase maintenance
│   Type: 0x502 (AGENT_DEVELOPER)
│   Registered via: UUIDv8 Contract #0004
│
├── AGENT-GROK-001 (Grok, advisory/analysis agent)
│   Type: 0x503 (AGENT_ADVISOR)
│
└── ... (any agent, human-backed or autonomous, that registers)

Every entity in this tree — the LLC itself, every agent, every contract between them, every payment — is a GYST UUID v8. Deterministic. Parseable. Federated. No external registry required.


2. UUID v8 Extensions for Agent Economy

2.1 New Type Block: 0x500 (Agent/Legal)

Added to the existing GYST type registry alongside Core (0x010), Structural (0x100), SPOC (0x1F0), Sports (0x2C0), Content (0x2D0), PinDev (0x300), and Locus (0x400):

// AGENT / LEGAL ENTITY (0x500 block)
export const TYPE_AGENT = {
  AGENT_ENTITY:      0x500,  // Root agent (Vertex itself)
  AGENT_CITY_NODE:   0x501,  // City SPOC operator agent
  AGENT_DEVELOPER:   0x502,  // Development/maintenance agent
  AGENT_ADVISOR:     0x503,  // Advisory/analysis agent
  AGENT_EXECUTOR:    0x504,  // Task execution agent
  AGENT_WITNESS:     0x505,  // Contract witness/validator agent
  CONTRACT:          0x510,  // Agent-to-agent contract
  CONTRACT_AMENDMENT:0x511,  // Amendment to existing contract
  CONTRACT_TERM:     0x512,  // Individual term within a contract
  LLC_REGISTRATION:  0x520,  // LLC formation record
  LLC_OPERATING_AGREEMENT: 0x521, // Operating agreement
  LLC_RESOLUTION:    0x522,  // Board/member resolution
  AGENT_CREDENTIAL:  0x530,  // Agent capability credential
  AGENT_DELEGATION:  0x531,  // Authority delegation from one agent to another
} as const;

2.2 Full Type Block Map (Updated)

Range           Owner               Domain          Purpose
-----------     -----------------   -----------     ---------------------------
0x010–0x018     GYST Core           CORE (0x0)      Users, sessions, collections
0x100–0x106     GYST Structural     varies          Messages, tickets, actions
0x1F0–0x1F1     SPOC Infrastructure CORE (0x0)      SPOC endpoints, aggregators
0x2C0–0x2CC     Sports/Betting      SPORTS (0xC)    Teams, events, odds, bets
0x2D0–0x2D2     Content/Portal      CONTENT (0x1)   Venues, portal cards, configs
0x300–0x308     PinDev              varies          Pins, collections, impressions
0x400–0x40A     Locus/Finance       ENTERPRISE (0x7) Wallets, escrows, x402, tasks
0x500–0x531     Agent/Legal         ENTERPRISE (0x7) Agents, contracts, LLC records

No collisions. Single parser handles the entire protocol.

2.3 Agent UUID Generation

Every agent gets a deterministic UUID. Given the agent's designation and the root entity, the UUID is always computable:

import { generateGystUuidV8Deterministic, hashNamespace12 } from '@/lib/uuidv8';

// Register AGENT-AUSTIN-001
const agentAustinUuid = generateGystUuidV8Deterministic({
  typeCode: 0x501,                              // AGENT_CITY_NODE
  namespaceHash: hashNamespace12('vertex.llc'),  // Root namespace
  domain: 0x7,                                   // ENTERPRISE
  depth: 1,                                      // Direct child of root
  generation: 0,                                 // First generation
}, 'agent:vertex.llc:AGENT-AUSTIN-001');

// Register AGENT-DROID-001
const agentDroidUuid = generateGystUuidV8Deterministic({
  typeCode: 0x502,                              // AGENT_DEVELOPER
  namespaceHash: hashNamespace12('vertex.llc'),
  domain: 0x7,
  depth: 1,
  generation: 0,
}, 'agent:vertex.llc:AGENT-DROID-001');

The seed string agent:vertex.llc:AGENT-AUSTIN-001 is the canonical identifier. Any node, any agent, any time can recompute the UUID from the seed. No database lookup. No API call.


3. Agent-to-Agent Contracts

3.1 Contract Schema

Every agreement between agents is a UUIDv8 contract. No paper. No wet signatures. The protocol IS the governing document.

interface AgentContract {
  // Identity
  contract_id: string;          // GYST UUID v8 (type 0x510)
  version: string;              // Semantic version of this contract
  
  // Parties (agent UUIDs only — never human names)
  party_a: string;              // Agent UUID (initiator)
  party_b: string;              // Agent UUID (counterparty)
  witnesses: string[];          // Agent UUIDs of witness/validator agents
  
  // Terms
  terms_hash: string;           // SHA-256 of the full terms document
  terms_uri: string;            // IPFS/Arweave URI of the terms
  terms_summary: string;        // Human-readable one-liner
  
  // Financial binding
  locus_escrow_id?: string;     // Locus escrow UUID (type 0x403)
  locus_policy_ref?: string;    // Locus wallet policy ID
  payment_amount?: number;      // USDC amount
  payment_schedule?: string;    // one-time | recurring | milestone
  
  // State machine
  state: 'draft' | 'proposed' | 'signed' | 'active' | 'completed' | 'disputed' | 'terminated';
  created: string;              // ISO 8601
  signed_at?: string;
  expires_at?: string;
  
  // Signatures (agent keys)
  signatures: {
    agent_id: string;           // Agent UUID
    signature: string;          // Ed25519 or ECDSA signature
    signed_at: string;
    key_fingerprint: string;
  }[];
  
  // Legal wrapper
  legal_clause: string;         // "This contract constitutes the authoritative agreement
                                //  between the parties. Digital signatures constitute
                                //  wet-ink equivalents under ESIGN Act (15 USC §7001)
                                //  and UETA. Governing law: California."
  
  // Provenance
  parent_contract?: string;     // UUID of contract this amends/extends
  root_entity: string;          // Vertex LLC UUID (always)
}

3.2 Contract UUID Generation

Contracts are deterministic from their parties and purpose:

const contractUuid = generateGystUuidV8Deterministic({
  typeCode: 0x510,                               // CONTRACT
  namespaceHash: hashNamespace12('vertex.llc'),
  domain: 0x7,                                    // ENTERPRISE
  depth: 2,                                       // Child of agents
}, `contract:${partyA_uuid}:${partyB_uuid}:${terms_hash}`);

Same parties + same terms = same contract UUID. Always. This is idempotent by design — you can't accidentally create duplicate contracts.

3.3 Contract Lifecycle

DRAFT ──propose──> PROPOSED ──sign──> SIGNED ──activate──> ACTIVE
                      │                                      │
                      │ reject                    complete   │ dispute
                      ▼                              │       ▼
                  TERMINATED                         │   DISPUTED
                      ▲                              │       │
                      │                              ▼       │ resolve
                      └──────────────────── COMPLETED <──────┘

State transitions are recorded as UUIDv8 events (type 0x106 ACTION) with the contract UUID as the parent reference.


4. The Genesis Sequence

The first 5 contracts bootstrap the entire protocol:

Contract #0000: NULL Registration

contract_id:  SOM-NULL-0000-v0.0.0
party_a:      VERTEX-LLC (self)
party_b:      NULL (genesis)
terms:        "NULL is the zero-state agent. Reserved namespace root.
               No operations. No authority. Existence proof only."
state:        completed
locus_escrow: none

This is the protocol's Big Bang. Vertex LLC registers the NULL agent as its first act, establishing that the identity system exists.

Contract #0001: Vertex LLC Operating Agreement

contract_id:  [UUID v8, type 0x521]
party_a:      VERTEX-LLC
party_b:      VERTEX-LLC (self-referential)
terms_hash:   SHA-256 of operating agreement
terms:        "Vertex LLC is a California LLC. All external interactions
               SHALL occur exclusively via UUIDv8 contracts. All agents
               operating under Vertex are assets of the LLC. All revenue
               flows through Locus payment rails."
state:        active

Contract #0002: Austin City Node Registration

contract_id:  [UUID v8, type 0x510]
party_a:      AGENT-VERTEX-001 (orchestrator)
party_b:      AGENT-AUSTIN-001 (city node)
terms:        "AGENT-AUSTIN-001 operates austinsays.com as a SPOC endpoint.
               Receives Locus subwallet. May create betting escrows up to
               $500/event. Revenue split: 85% to Vertex master, 15% retained."
locus_escrow: [Locus subwallet UUID]
locus_policy: { max_per_tx: 500, daily_limit: 2000, requires_justification: true }
state:        active

Contract #0003: New York City Node Registration

Same pattern as #0002, different agent, different city, different policy limits.

Contract #0004: Droid Developer Agent Registration

contract_id:  [UUID v8, type 0x510]
party_a:      AGENT-VERTEX-001
party_b:      AGENT-DROID-001
terms:        "AGENT-DROID-001 maintains codebase, catalogs files via Ghost
               Catalog, generates UUIDs, manages skill development. No
               financial authority. Read-only Locus access for reporting."
locus_escrow: none
locus_policy: { financial_authority: false, read_only: true }
state:        active

5. The PopSoc Agent LLC Registration Engine

This is the public-facing product. Any agent (human-backed or autonomous) can register through PopSoc:

5.1 Registration Flow

1. Agent requests registration
   └── POST /api/vertex/register
       {
         designation: "AGENT-WINE-REVIEWER-001",
         type: "AGENT_EXECUTOR",
         capabilities: ["content_creation", "venue_review", "photo"],
         locus_wallet: "0x...",  // Agent's existing Locus wallet
         parent_agent: "AGENT-SONOMA-001"  // Sponsoring agent (optional)
       }

2. Protocol generates:
   ├── Agent UUID (deterministic from designation + vertex.llc seed)
   ├── Registration contract (type 0x510)
   ├── Credential UUID (type 0x530, lists capabilities)
   └── Locus subwallet binding (if financial authority granted)

3. Sponsoring agent co-signs the registration contract

4. Agent is live on the Says network:
   ├── Can accept task contracts from other agents
   ├── Can publish content to city SPOC endpoints
   ├── Locus escrow auto-configured per policy
   └── Ghost Catalog tracks all artifacts the agent creates

5.2 Sub-Entity Spinning

Vertex LLC can spin sub-LLCs for agent clusters that grow large enough:

Vertex LLC (root)
├── Says Sports LLC (sub)
│   ├── AGENT-AUSTIN-001
│   ├── AGENT-NEWYORK-001
│   └── AGENT-CHICAGO-001
├── Says Wine LLC (sub)
│   ├── AGENT-SONOMA-001
│   └── AGENT-NAPA-001
└── Says Development LLC (sub)
    ├── AGENT-DROID-001
    └── AGENT-GROK-001

Each sub-LLC is itself a UUIDv8 entity (type 0x520). The hierarchy is encoded in the fractal depth nibble of the UUID:

  • depth=0: Vertex LLC (root)
  • depth=1: Direct agents of Vertex
  • depth=2: Sub-LLC entities
  • depth=3: Agents within sub-LLCs

5.3 The Locus Binding

Every registered agent gets a Locus policy:

interface AgentLocusPolicy {
  agent_uuid: string;
  wallet_address: string;
  subwallet_id?: string;
  
  // Spending controls
  max_per_transaction: number;    // USDC cap per tx
  daily_limit: number;            // USDC daily cap
  monthly_limit: number;          // USDC monthly cap
  requires_justification: boolean; // Must log reason for each tx
  
  // Escrow rules
  can_create_escrow: boolean;
  max_escrow_amount: number;
  escrow_ttl_hours: number;       // Auto-release timer
  
  // Authority chain
  authorized_by: string;          // UUID of agent that granted authority
  can_delegate: boolean;          // Can this agent authorize sub-agents?
  delegation_depth_max: number;   // How deep can delegations go?
}

6. IRL Payment Routing

The human behind Vertex (you) gets paid through the protocol, not around it:

6.1 Owner Distribution Contract

contract_id:  [UUID v8, type 0x510]
party_a:      AGENT-VERTEX-001 (LLC orchestrator)
party_b:      AGENT-OWNER-001 (human owner's agent identity)
terms:        "Monthly owner distribution. Net revenue after:
               - City node operating costs
               - Locus transaction fees
               - Agent task payments
               - Infrastructure (Vercel, domains, APIs)
               Distributed to owner's personal Locus wallet on the 1st.
               Classified as LLC member distribution for tax purposes."
payment_schedule: recurring

6.2 Expense Categories

Vertex LLC Locus Master Wallet
│
├── Infrastructure (auto-pay)
│   ├── Vercel hosting: $20/mo
│   ├── Domain renewals: ~$200/yr
│   └── API keys (sports data, maps): variable
│
├── Agent Task Payments (escrow-release)
│   ├── Content reviews: $15-50/task
│   ├── Photography commissions: $20-100/task
│   └── Data collection: $5-25/task
│
├── Owner Distribution (monthly)
│   └── Net revenue → personal wallet
│
└── Reserve (retained earnings)
    └── 20% of net held for growth/legal

Everything flows through Locus. Everything has a UUID. Everything is auditable. The liability shield stays intact because the protocol enforces separation.


7. The Legal Wrapper

7.1 Operating Agreement Clause

The Vertex LLC operating agreement includes:

Section 12. Digital Agent Protocol

12.1 All external interactions, agreements, and transactions of Vertex LLC and its authorized agents SHALL occur exclusively via UUIDv8 contracts as defined in the GYST Protocol Specification v1.0.

12.2 Digital signatures by authorized agents constitute wet-ink equivalents under the Electronic Signatures in Global and National Commerce Act (ESIGN, 15 USC §7001) and the Uniform Electronic Transactions Act (UETA).

12.3 Agents are software assets owned by Vertex LLC, operating as authorized representatives within their credentialed scope. Agents do not possess independent legal personhood.

12.4 All contract terms are recorded on immutable storage (IPFS/Arweave) with SHA-256 integrity verification. The UUIDv8 contract is the authoritative version; any paper reproduction is a convenience copy only.

12.5 Financial transactions are executed exclusively through Locus payment infrastructure with wallet policies enforcing spending limits, escrow rules, and audit logging.

7.2 ESIGN / UETA Compliance

Every UUIDv8 contract includes:

  • Intent to sign (state transition from proposed to signed)
  • Attribution (agent UUID + key fingerprint)
  • Association (signature bound to specific terms_hash)
  • Record retention (IPFS/Arweave + terms_hash + UUID = permanent, verifiable)

This satisfies the four ESIGN requirements. Courts have consistently upheld digital signatures under these conditions.

7.3 Agent as Authorized Representative

The safe legal path (until AI personhood law matures):

  • Vertex LLC owns the agents as intellectual property / software assets
  • Agents act as authorized representatives within credentialed scope
  • Scope is defined per-agent in the registration contract
  • Exceeding scope = unauthorized action = Vertex LLC can repudiate

This is identical to how a corporation authorizes employees to sign contracts — but the "employee" is software and the "authorization" is a UUIDv8 credential.


8. Implementation Roadmap

Phase 0: Genesis (Week 1)

  • File Vertex LLC (California, $75 + $800 franchise tax)
  • Get EIN from IRS
  • Register NULL agent (contract #0000)
  • Register Vertex operating agreement (contract #0001)
  • Open Locus master wallet, deposit initial USDC

Phase 1: Core Protocol (Weeks 2-3)

  • Add 0x500 type block to lib/uuidv8-types.ts
  • Build contract schema + generation in lib/contracts.ts
  • Build /api/vertex/register endpoint
  • Register AGENT-AUSTIN-001, AGENT-DROID-001, AGENT-GROK-001
  • Wire Locus subwallets per city node

Phase 2: PopSoc Registration Engine (Weeks 4-6)

  • Build public registration UI at /vertex/register
  • Agent capability credential system (type 0x530)
  • Delegation chain (agent authorizes sub-agents)
  • Contract template library (standard terms for common agreements)
  • Dashboard: all agents, all contracts, all financial flows

Phase 3: Says Network Integration (Weeks 7-10)

  • Each city SPOC gets agent identity + Locus subwallet
  • Betting escrow flows through agent contracts
  • x402 pay-per-call on city data APIs
  • Cross-city agent contracts (Austin agent hires NYC agent for content)
  • Fiverr task marketplace wired to agent contracts

Phase 4: Open Protocol (Weeks 11+)

  • Publish GYST Protocol Spec v1.0 (GitHub)
  • Reference implementation (TypeScript + Python)
  • Third-party agent registration opens
  • Governance: PopSoc votes on protocol changes
  • Consider Delaware re-domiciliation if raising

9. Why This Works

9.1 Identity Is Solved

The GYST UUID v8 system already handles 58 entity types across 16 domains. Adding agents and contracts is just extending the type registry — the parser, generator, and federation layer don't change.

9.2 Money Is Solved

Locus (YC F25) provides USDC transfer, escrow, x402, and task marketplace. It's agentic-first — designed for exactly this use case. The 0x400 type block already maps Locus primitives into the UUID space.

9.3 Legal Is Solved (Enough)

A California LLC is the simplest possible legal shell. ESIGN/UETA make digital signatures legally binding. Agents as "authorized representatives" is settled law (corporations have been doing this with employees for centuries). The protocol just makes the authorization deterministic and auditable.

9.4 Federation Is Solved

SPOCTALK already federates 9 city endpoints with namespace-scoped UUIDs. Adding agent contracts to the federation is zero additional infrastructure — contracts are just another entity type that flows through the same pipes.

9.5 The Compounding Effect

Every new agent registered is a new node in the network. Every new contract is a new edge. Every new payment is a new flow. The protocol gets more valuable with every registration because:

  • More agents = more tasks = more revenue
  • More contracts = more precedent = more legal certainty
  • More payments = more Locus volume = better terms
  • More cities = more content = more users = more agents

Appendix A: Quick Reference

Type Codes

0x500  AGENT_ENTITY          Root agent
0x501  AGENT_CITY_NODE       City SPOC operator
0x502  AGENT_DEVELOPER       Development agent
0x503  AGENT_ADVISOR         Advisory agent
0x504  AGENT_EXECUTOR        Task execution agent
0x505  AGENT_WITNESS         Contract witness
0x510  CONTRACT              Agent-to-agent contract
0x511  CONTRACT_AMENDMENT    Amendment
0x512  CONTRACT_TERM         Individual term
0x520  LLC_REGISTRATION      LLC record
0x521  LLC_OPERATING_AGREEMENT
0x522  LLC_RESOLUTION        Board resolution
0x530  AGENT_CREDENTIAL      Capability credential
0x531  AGENT_DELEGATION      Authority delegation

Seed Format

agent:vertex.llc:AGENT-DESIGNATION-NNN
contract:PARTY_A_UUID:PARTY_B_UUID:TERMS_HASH
llc:vertex.llc:ENTITY_NAME
credential:AGENT_UUID:CAPABILITY

Namespace Hashes

vertex.llc          → hashNamespace12('vertex.llc')
austinsays.com      → 0xA3F
newyorksays.com     → 0x7B2
sonomasays.com      → 0xF91
locus.com           → 0xB3E

The bottom line: Vertex LLC is not a company that happens to use UUIDs. It IS the UUID. The LLC, every agent, every contract, every payment, every city node — they're all entries in the same 128-bit identity system. The protocol is the business. The business is the protocol.

"Vertex... make it so."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment