TRIS Activation

TRIS Activation

TRIS Activation is the process of issuing a verifiable, privacy-preserving identity for Humans, Organizations, and AI Agents. Activation establishes: (1) a TRIS ID + DID document, (2) the verification tier, and (3) eligibility to participate in the trust economy under role-appropriate permissions.

All raw credentials and proofs remain off-chain. Only hashed commitments and epoched credential tiers are anchored for verifiability.

1) Activation Overview

Actor Type
Verification Method(s)
Identifier Style
Primary Network Role

Human

zk-KYH / zk-KYC (ID only / ID + AML)

@username (pseudonymous)

Build and earn credibility; submit & disclose selectively

Organization

zk-KYB (Side A + Side B)

tris.org:<handle>

Validate, enforce, and anchor institutional policies

AI Agent

zk-KYA (Registrant co-sign + fingerprint)

tris.ai:<handle>

Operate with verified accountability under a Registrant

2) Human Activation

Goal: establish uniqueness/identity without exposing PII; preserve pseudonymity by default.

Tier
Description

zk-KYH

Confirms “one human = one TRIS” with zero-knowledge uniqueness proof.

zk-KYC (ID only)

Verifies government-issued identity (no AML); PII never leaves the prover.

zk-KYC (ID + AML)

Adds AML screening + liveness for regulated contexts.

Pseudonymity & Handle Rules

  • Humans appear as @handle; legal names are never published by Tythe.

  • Handles are globally unique and mapped to TRIS via commitment proofs.

  • Visibility of any attribute is governed by user-controlled disclosure.

Activation Flow (Human)

  1. Wallet connection → nonce signing (SIWE/OAuth2.0-PKCE).

  2. Select verification tier (zk-KYH / KYC / KYC+AML) and complete proof.

  3. Issue TRIS ID + DID; initialize Trovebook; enable DISC eligibility.

Outputs

  • TRIS ID (DID), verification tier, Trovebook created (private), DISC eligibility active.

3) Organization Activation

Goal: verify organizational legitimacy across on-chain control and off-chain presence without revealing sensitive internals.

zk-KYB Requirements

  • Side A (Ownership): Smart Contract Ownership or Treasury Wallet Signature or Tythe Challenge.

  • Side B (Presence): DNS or GitHub or Twitter (via zkTLS/Reclaim).

Identifier & Protection

  • Organizations are addressed as @<handle>.org to prevent impersonation.

  • Legal entity metadata is never exposed by default.

Activation Flow (Org)

  1. Submit Side A + Side B proofs.

  2. zk-KYB verified; TRIS issued with .org suffix.

  3. Organization registered; Validator & Policy tooling unlocked (post-verification).

Outputs

  • TRIS ID (Org), Vetted status, access to Validator Hub / Compliance Center.

4) AI Agent Activation

Goal: bind an Agent to a responsible Registrant with an auditable behavioral fingerprint.

Requirements

  • Registrant: a verified Human or Organization co-signs the registration.

  • Behavioral Fingerprint: salted hash over agent metadata, action schema, and Registrant TRIS.

  • zk-KYA: verifies authenticity and binding without revealing internals.

Identifier & Protection

  • Agents are addressed as @<handle>.ai; provenance is explicit via Registrant linkage.

Activation Flow (Agent)

  1. Registrant initiates agent registration and co-signs.

  2. Generate behavioral fingerprint + zk-KYA proof.

  3. Issue Agent TRIS + DID; initialize read-only Trovebook for behavioral traces.

Outputs

  • TRIS ID (Agent), Registrant binding, DISC eligibility (agent class), visibility controls.

5) Activation Evidence & Privacy

Surface
Where it lives
What’s shared on-chain

Proof artifacts (raw)

Off-chain (encrypted storage)

None

Credential tier state

Off-chain bundle + credentialsRoot

Epoched inclusion (tierBitmap; no PII)

DID & keys

TRISRegistry

DID hash + key references (no PII)

Scores/Metrics

DISC off-chain + metricRoot/scoreRoot

Epoched inclusion (active metrics only)

Note: AP checks rely on off-chain attestation bundles with Merkle proofs to credentialsRoot (tierBitmap), not raw documents.

6) Re-verification, Refresh, and Revocation

Lifecycle Event
Human
Organization
AI Agent

Proof Refresh

Triggered by user; rotates credential epoch

Admin-initiated or policy-driven

Registrant-initiated; fingerprint can roll

Key Rotation

Yes (TRISRegistry)

Yes (TRISRegistry)

Yes (TRISRegistry)

Revocation

User-initiated or BAD-Status enforcement

Org-initiated or BAD-Status enforcement

Registrant-initiated or BAD-Status enforcement

Visibility Controls

Per-metric / per-report disclosures

Policy visibility scope

Registrant + agent scope

7) Failure Cases & Safeguards

  • Duplicate Attempts: zk-KYH prevents multi-TRIS issuance for the same human.

  • Mismatched Ownership (Org): Side A proof fails → activation halted with receipt.

  • Unbound Agent: No valid Registrant co-signature → activation rejected.

  • Stale Credentials: AP checks reference epoch; stale tierBitmap fails strict policies until refreshed.

  • BAD Status: Can suspend disclosure, disable AP eligibility, and block policy participation pending resolution.

8) Activation Outputs (Summary)

Actor
Issued Artifacts
Capabilities Unlocked

Human

TRIS ID + DID, verification tier

Trovebook (private), DISC eligibility, selective disclosure

Organization

TRIS ID (.org), Vetted status

Validator Hub, Access/Validation Policies, compliance tooling

AI Agent

TRIS ID (.ai), Registrant binding

Behavioral trace visibility, DISC eligibility (agent class)

9) Principles (Design Constraints)

  • Privacy First: No PII on-chain; all disclosures are user/role-scoped.

  • Role Integrity: Verification type determines permissions, not reputation.

  • Auditability by Epoch: Credential tiers and scores are verifiable against weekly roots.

  • Minimal On-Chain Logic: Contracts anchor identity and state roots only; all computation is off-chain.

PreviousTRIS Compatibility NextTRIS Security

Last updated

Was this helpful?