Version 3.1 | April 2025

This document presents an integrated design for Reddcoin's two-tiered auction system with a complementary identity linking layer. The system builds upon the existing Reddcoin infrastructure to create a fair, efficient, and economically sustainable mechanism for allocating human-readable identifiers and identity profiles within the Reddcoin ecosystem.

The integrated system is composed of three interrelated components:

1. Namespace Auction System - For registering top-level namespaces (.redd, .crypto, etc.)
2. User ID Auction System - For registering user identifiers within namespaces (alice.redd, bob.crypto)
3. ReddID Profile System - For establishing cross-namespace identity profiles with social features

The design implements a hierarchical structure where top-level namespaces are auctioned first, those namespace owners define rules for user IDs within their namespace, and ReddIDs provide a cross-namespace identity layer that connects user IDs across the system through direct registration rather than auctions.

This approach achieves several key objectives:

1. Market-driven price discovery for valuable namespaces and user IDs
2. Prevention of squatting through economic disincentives
3. Creation of deflationary pressure on RDD supply
4. Sustainable funding for ongoing development
5. Rewards for network participants through fee distribution
6. Simplified registration process for cross-namespace identities
7. Establishment of a reputation and identity layer across the Reddcoin ecosystem

1. System Overview
2. Core Architecture
3. Auction Mechanics
4. Identity Features
5. Blockchain Integration
6. P2P Protocol Extensions
7. Database Schema
8. Economic Model
9. User Interface Design
10. Implementation Plan
11. Governance Framework
12. Interoperability
13. Appendices

The Reddcoin Identity and Naming System implements a three-tier architecture:

1. Namespaces (Top Level)

   • Analogous to top-level domains (.com, .org) in DNS
   • Examples: .redd, .crypto, .gaming, .finance
   • Controlled by namespace owners who define rules and economic parameters
   • Auctioned with highest minimum prices (10,000-100,000 RDD)

2. User IDs (Second Level)

   • Identifiers within a specific namespace
   • Examples: alice.redd, bob.crypto, store.finance
   • Follow the rules established by namespace owners
   • Auctioned with namespace-specific price tiers

3. ReddIDs (Cross-Namespace Identity)

   • Cross-namespace identity profiles
   • Link multiple user IDs across namespaces to a single identity
   • Provide reputation, social connections, and profile features
   • Directly registered with a fee set by the namespace owner

The integrated system consists of these key components:

1. ReddIDManager: Central controller orchestrating all identity and naming systems
2. NamespaceManager: Handles namespace operations and configuration
3. AuctionManager: Manages auction processes for namespaces and user IDs
4. ProfileManager: Manages ReddID profiles, social connections, and reputation
5. ReddIDDB: Database layer for persistent storage of all system data
6. ReddIDP2PManager: P2P protocol extensions for network communication

The system implements a strict hierarchical relationship where:

1. Namespaces must exist before any User IDs can be registered within them
2. Namespace parameters control and restrict User ID parameters
3. User IDs must exist before they can be linked to a ReddID
4. ReddIDs provide cross-namespace identity linking and social features
5. Ownership of user IDs and ReddIDs is verified using cryptographic keys
6. Revenue from lower tiers flows partially to higher tiers creating aligned incentives

The core architecture consists of the following components:

• Central controller for the entire identity and naming system
• Coordinates interaction between all components
• Implements validation interface for blockchain integration
• Manages lifecycle of all components
• Provides public API for applications and wallet integration

• Handles namespace registration, configuration, and renewals
• Enforces namespace auction rules
• Stores and validates namespace parameters
• Transfers namespace ownership
• Manages namespace expiration and grace periods

• Implements auction mechanisms for namespaces and user IDs
• Processes bids, finalization, and settlements
• Distributes auction proceeds according to revenue models
• Extends auctions based on anti-sniping rules
• Manages auction states through their lifecycle

• Manages ReddID profiles and properties
• Handles social connections between ReddIDs
• Calculates and stores reputation metrics
• Provides namespace resolution for ReddIDs
• Manages cross-namespace identity linking

• Persistent storage layer for all system data
• Implements schema for namespaces, user IDs, and ReddIDs
• Stores auction history and bid information
• Manages social graph data and reputation history
• Provides efficient query mechanisms

• Extends the Reddcoin P2P protocol for identity and naming
• Propagates auction announcements and bids
• Distributes profile updates and social connections
• Synchronizes namespace configurations
• Validates reputation calculations

The interaction between components follows these main flows:

1. Namespace Creation

   • User requests namespace auction creation via NamespaceManager
   • AuctionManager creates and validates auction parameters
   • ReddIDP2PManager announces auction to network
   • After auction ends, NamespaceManager configures the new namespace

2. User ID Registration

   • User requests ID auction within a namespace
   • AuctionManager validates against namespace rules
   • After auction ends, ID is registered to winner
   • Revenue is distributed according to namespace parameters

3. ReddID Registration

   • User requests ReddID registration via ProfileManager
   • ProfileManager validates the request and collects the registration fee
   • The fee is distributed according to namespace parameters
   • ReddID is registered and profile created

4. Cross-Namespace Resolution

   • ReddID links to multiple User IDs across namespaces
   • Resolution requests are processed by ProfileManager
   • Linked identities can be discovered and verified

The system integrates with the Reddcoin ecosystem through:

1. Blockchain Integration: Via OP_RETURN transactions for all state changes
2. Wallet Integration: For bid placement, profile management, and key management
3. Node Integration: For P2P message propagation and validation
4. RPC Interface: For application interaction and user interface support
5. External API: For third-party service integration

The system implements specialized auction types for each tier:

• Standard Auctions: Default for most namespace names

  • Duration: 14-30 days
  • Deposit: 20% of bid amount
  • Reserve price: 10,000-100,000 RDD based on length

• Premium Auctions: For high-value namespace names

  • Longer duration: 30 days
  • Higher deposit: 25% of bid amount
  • Higher reserve prices: 2-5x standard prices

• Standard Auctions: Default auction type for most names

  • Duration defined by namespace (typically 3-7 days)
  • Deposit requirement defined by namespace (typically 10%)
  • Reserve price determined by namespace length-based pricing tiers

• Premium Auctions: For high-value names (short, dictionary words)

  • Longer duration (typically 7-14 days)
  • Higher deposit requirement (typically 15-20%)
  • Higher reserve prices

• Renewal Auctions: For names approaching expiration

  • Current owner gets right of first refusal
  • If not renewed, enters public auction
  • Grace period implemented before public auction

All auctions follow a standardized state flow with variations by type:

[Initial State] → [Auction Creation] → [Auction Open] → [Auction Ended] → [Settlement] → [Ownership]

Key state transitions include:

1. Auction Creation: Creator establishes parameters and makes deposit
2. Auction Open: Bidding period active, bids must exceed minimum increment
3. Anti-Sniping Extensions: Extensions triggered by late bids to prevent sniping
4. Auction Ended: Bidding closed, awaiting finalization
5. Settlement: Highest bidder wins, proceeds distributed, losing bids refunded
6. Ownership Period: Winner receives ownership with renewal requirements

Each tier implements tier-specific bidding rules, with common features:

1. Minimum Increments:

   • Namespaces: 5% minimum bid increment
   • User IDs: Namespace-defined increment (typically 5%)

2. Deposit Requirements:

   • Namespaces: 20% deposit of bid amount
   • User IDs: Namespace-defined deposit (typically 10-15%)

3. Anti-Sniping Protection:

   • Namespaces: 12-hour extension if bid placed within final 24 hours
   • User IDs: Namespace-defined extension (typically 12-24 hours)

4. Bid Validation:

   • All bids must include proof of funds
   • Bids must be cryptographically signed by bidder
   • Bids below minimum increment are rejected
   • Bids below reserve price are rejected

The settlement process follows these steps:

1. Once auction time elapses, the auction enters the finalization phase
2. The highest valid bid is identified as the winner
3. The winner's full bid amount is processed
4. Auction proceeds are distributed according to the tier-specific revenue model
5. Deposits from losing bidders are refunded (minus processing fees)
6. The resource (namespace or user ID) is registered to the winner's address
7. All participants are notified of the auction outcome

ReddIDs are registered directly rather than through auctions, with the following process:

1. Fee Determination:

   • Registration fees are set by namespace owners
   • Fees vary based on factors like name length and desirability
   • Premium names may have higher registration fees

2. Registration Process:

   • User selects a unique ReddID identifier
   • System validates availability and eligibility
   • User pays the registration fee
   • Fee is distributed according to namespace parameters
   • ReddID is assigned to the user's cryptographic key

3. Renewal Process:

   • Annual renewal fees to maintain ReddID ownership
   • Fees determined by namespace configuration
   • Usage discounts for active ReddIDs
   • Grace period for late renewals

Each ReddID includes a standardized profile structure:

1. Core Identity:

   • ReddID (primary identifier)
   • Display name (customizable)
   • Avatar/profile image (IPFS hash)
   • Bio/description (limited to 256 characters)

2. Contact Information:

   • Optional email hash (for verification, not displayed publicly)
   • Optional social media identifiers (Twitter, Discord, etc.)
   • Messaging public key (for encrypted communications)

3. Verification Status:

   • Self-attested information
   • Community-verified indicators
   • Official verification badges (for legally registered entities)

4. Namespaces Resolution:

   • Linked User IDs across multiple namespaces
   • Default namespace for payments
   • Namespace-specific settings

The ReddID system includes a built-in reputation framework:

1. Reputation Metrics:

   • Network longevity (time ReddID has been active)
   • Transaction volume (total RDD transacted)
   • Community engagement (social interactions)
   • Verification depth (number and quality of verifications)
   • Auction behavior (bidding history, payment reliability)

2. Calculation Method:

   • Base score from verifiable on-chain activity
   • Weighted aggregate of individual metrics
   • Decay function for inactive ReddIDs
   • Protection against manipulation attempts

3. Display and Usage:

   • Numeric score (0-100)
   • Visual indicator in UI
   • Accessible via API for third-party applications
   • Optional opt-out (with corresponding display indicator)

ReddIDs support social connectivity within the ecosystem:

1. Connection Types:

   • Follow (one-way connection)
   • Friend (two-way, mutual connection)
   • Endorsement (reputation-affecting connection)
   • Block (negative connection)

2. Privacy Controls:

   • Public, friends-only, or private visibility settings
   • Granular permission settings for data sharing
   • Encrypted messaging options

3. Discovery Mechanisms:

   • Directory search with filtering
   • Suggested connections based on activity
   • Namespace-based grouping
   • Reputation-weighted recommendations

ReddIDs serve as master identifiers across the namespace system:

1. Resolution Protocol:

   • Bidirectional mapping between ReddID and namespace-specific IDs
   • Priority resolution for conflicts (ReddID takes precedence)
   • Standardized addressing format: id@reddid or id@namespace

2. Update Propagation:

   • Changes to ReddID profile cascade to linked namespaces where applicable
   • Namespace-specific settings can override global settings
   • History of changes is maintained for auditability

3. Identifier Management:

   • Centralized management interface for all linked identifiers
   • Batch operations across multiple namespaces
   • Migration tools for consolidating identities

The system uses Reddcoin's OP_RETURN capability to record identity and naming data on-chain, with specialized formats for each operation type.

Namespace Auction Creation

0     2  3          7    8         16   17   25    26     34       35    39          74  
|-----|--|----------|----|---------|----|-----|-----|------|---------|----|----------|
magic op  auctionId type nameHash  ns   start  end  reserve depositPct configHash

Namespace Bid Placement

0     2  3          7    8       16    17    25
|-----|--|----------|----|---------|----|-----|
magic op  auctionId hash bidAmount time

Namespace Auction Finalization

0     2  3          7    8       16    17    25
|-----|--|----------|----|---------|----|-----|
magic op  auctionId hash winAmount time

User ID Auction Creation

0     2  3                             39  
|----|--|-----------------------------|  
magic op   name.namespace_id (37 bytes)

User ID Bid Placement

0     2  3          7    8       16    17    25
|-----|--|----------|----|---------|----|-----|
magic op  auctionId hash bidAmount time

User ID Auction Finalization

0     2  3                             39  
|----|--|-----------------------------|  
magic op   name.namespace_id (37 bytes)

ReddID Registration

0     2  3                             35  36    44    45    109
|----|--|-----------------------------|-----|-----|------------|
magic op   reddid_id (32 bytes)       time  fee   profile_hash

ReddID Profile Update

0     2  3                             35   36    100
|----|--|-----------------------------|-----|-----|
magic op   reddid_id (32 bytes)       time  ipfs

ReddID Connection Operation

0     2  3                             35   36                             68   69   70
|----|--|-----------------------------|-----|-----------------------------|----|----|
magic op   from_reddid (32 bytes)     to_reddid (32 bytes)               type flag

The system defines the following operation codes:

New consensus rules are implemented to enforce:

• Validity of naming and identity operations
• Uniqueness of identifiers across the system
• Correct sequence of state transitions
• Appropriate fee payments
• Authorization of operations
• Namespace rule compliance
• Profile data validity requirements

The P2P protocol is extended with new message types to support the identity and naming system:

Since the full namespace configuration and profile data are too large for OP_RETURN, they're distributed through the P2P network:

1. When a namespace auction is finalized, the winner's configuration is stored locally
2. A configuration hash is included in the blockchain transaction
3. Nodes can request the full configuration by sending a MSG_NAMESPACE_CONFIG_REQUEST
4. Nodes with the configuration respond with a MSG_NAMESPACE_CONFIG_RESPONSE
5. Receiving nodes validate the configuration against the hash from the blockchain

Similar to namespace configurations, profile data is distributed via P2P:

1. Primary P2P Distribution:

   • When a profile is created or updated, the data is stored locally
   • A hash (either IPFS or direct) is included in the blockchain transaction
   • Nodes can request the full profile with a MSG_REDDID_PROFILE_REQUEST
   • Nodes with the profile respond with a MSG_REDDID_PROFILE_RESPONSE

2. IPFS Storage Option:

   • Profile data can be stored on IPFS for redundancy
   • IPFS hash is recorded in applicable OP_RETURN operations
   • Provides alternative retrieval method if P2P network is unavailable

3. Caching Strategy:

   • Frequently accessed profiles are cached by nodes
   • TTL-based cache expiration to ensure updates propagate
   • Prioritized caching based on connection proximity and reputation

Nodes can subscribe to specific types of identity and naming events:

1. Namespace Subscription:

   • Nodes can subscribe to specific namespaces of interest
   • Filter by namespace ID to receive only relevant updates
   • Prioritize relay to interested nodes

2. ReddID Subscription:

   • Nodes can subscribe to specific ReddIDs of interest
   • Filter updates based on social proximity
   • Prioritize updates from high-reputation identities

3. Efficient Relay:

   • Messages are relayed based on subscription preferences
   • Nodes maintain subscription tables for efficient routing
   • Time-sensitive messages (bids, auction endings) receive priority

Stores core namespace configuration.

Stores pricing tiers for different name lengths within a namespace.

Stores information about registered user IDs.

Stores information about all auctions in the system.

Stores information about all bids placed.

Stores core profile information for each ReddID.

Stores reputation information for ReddIDs.

Stores social connections between ReddIDs.

Maps ReddIDs to namespace-specific user IDs.

Each tier of the system implements a specialized revenue distribution model to create aligned incentives throughout the ecosystem.

For each successful namespace auction, the revenue is distributed as:

For each successful user ID auction, the proceeds are distributed according to the parent namespace configuration:

For ReddID registration and renewal fees, the revenue is distributed as:

Pricing across the system varies by tier and follows these general principles:

Based primarily on length, with shorter names commanding premium prices:

• Single character: 100,000 RDD minimum
• Two characters: 50,000 RDD minimum
• Three characters: 25,000 RDD minimum
• Four+ characters: 10,000 RDD minimum

Defined by namespace-specific pricing tiers, but generally following:

• Short names (1-2 characters): Premium pricing (typically 50,000-100,000 RDD)
• Medium names (3-4 characters): High pricing (typically 10,000-25,000 RDD)
• Standard names (5-9 characters): Moderate pricing (typically 5,000-10,000 RDD)
• Long names (10+ characters): Base pricing (typically 2,500-5,000 RDD)

Direct registration fees set by namespace owners, typically following:

• Premium ReddIDs (3-4 characters): 20,000-30,000 RDD
• Standard ReddIDs (5-8 characters): 5,000-10,000 RDD
• Long ReddIDs (9+ characters): 2,500-5,000 RDD

Additional factors affecting price include:

• Dictionary words
• Common names
• Numeric-only IDs
• Pattern-based IDs (repeating characters, sequences)
• Verification status

The renewal model balances stability with prevention of squatting:

• Renewal Period: 180-730 days (configurable, default 365 days)
• Grace Period: 14-60 days (configurable, default 30 days)
• Renewal Fee: 25% of equivalent auction price
• Reclamation: If not renewed during grace period, enters public auction

• Renewal Period: Defined by namespace (typically 365 days)
• Grace Period: Defined by namespace (typically 30 days)
• Renewal Pricing: Based on namespace configuration:
  • Standard renewal: Percentage of equivalent auction price (typically 50%)
  • Grace period renewal: Higher percentage (typically 75-100%)
  • Usage discounts: Reduced fees for actively used IDs

• Renewal Period: 365 days standard
• Grace Period: 30 days after expiration
• Renewal Pricing:
  • Active ReddIDs (high reputation score): 25% of registration fee
  • Standard renewal: 50% of registration fee
  • Grace period renewal: 75% of registration fee

The system implements multiple anti-squatting mechanisms across all tiers:

1. Economic Disincentives:

   • High initial acquisition costs through auction mechanism for namespaces and user IDs
   • Substantial registration fees for ReddIDs
   • Substantial renewal fees
   • Progressively higher costs for bulk ownership

2. Usage Requirements:

   • Activity-based renewal discounts
   • Transaction count tracking
   • Reputation impacts for inactive IDs

3. Ownership Limitations:

   • Progressively higher pricing for multiple premium identifiers
   • Verification requirements for high-value identifiers
   • Time-delay between multiple registrations

4. Governance Controls:

   • Reserved names for trademark holders
   • Dispute resolution process
   • Malicious use penalties

Key features include:

• Filtering by namespace status and characteristics
• Search functionality for specific namespaces
• Detail view showing configuration and auction status
• One-click access to bidding interface

Key features include:

• Primary organization by namespace
• Filtering by auction type and status within namespace
• Search functionality for specific names across namespaces
• Clear display of namespace rules and requirements
• One-click access to bidding interface

Key features include:

• Username availability checker
• Fee calculator based on namespace and name characteristics
• Profile setup wizard
• Payment processing
• Linking to existing user IDs

Key elements include:

• Clear auction information and status
• Current highest bid information
• Minimum bid requirement calculation
• Deposit amount calculation
• Countdown timer for auction end
• Confirmation controls

Key features include:

• Organization of owned resources by type (namespaces, user IDs, ReddIDs)
• Active bids tracking across all auction types
• Auction watchlist with filtering
• Notification center with alerts
• Renewal reminders grouped by type

Key sections include:

• Basic profile editor with avatar and bio
• Verification status and upgrade options
• Connected namespace identities
• Social connection management
• Privacy and visibility settings
• Reputation score breakdown

Key features include:

• Connection visualization and management
• Activity feed of connected ReddIDs
• Reputation trending indicators
• Messaging interface (direct and encrypted)
• Discovery recommendations

Key aspects include:

• Simplified profile view and editing
• QR code for easy identity sharing
• Quick connection management
• Notification center for identity interactions
• Streamlined verification processes

The implementation follows a phased approach to ensure stable, sequential deployment:

The implementation follows a clear dependency chain:

1. Namespace System: Must be implemented first as the foundation
2. User ID System: Depends on namespace system for rules and parameters
3. ReddID System: Integrates with both prior systems for cross-namespace functionality

1. Core Protocol Extensions:

   • Define OP_RETURN formats for all operations
   • Implement validation rules for each resource type
   • Create consensus rules for system operations

2. Database Development:

   • Implement comprehensive database schema
   • Create efficient indexing for common queries
   • Develop synchronization mechanisms

3. P2P Protocol Extensions:

   • Implement all message types and handlers
   • Create configuration distribution system
   • Develop subscription mechanisms

4. Economic System Implementation:

   • Implement revenue distribution logic
   • Create pricing tier calculation systems
   • Develop fee calculation algorithms

5. Identity System Implementation:

   • Implement profile data structures
   • Create reputation calculation algorithms
   • Develop social connection framework
   • Implement direct registration process for ReddIDs

6. User Interface Development:

   • Create auction browsers for namespaces and user IDs
   • Build ReddID registration interface
   • Develop configuration and management interfaces
   • Create identity and social dashboards
   • Develop mobile-optimized experiences

The Reddcoin platform maintains governance over system-wide parameters:

1. Parameter Boundaries:

   • Minimum/maximum values for namespace configuration
   • Revenue distribution ranges
   • System-wide fee minimums
   • Protocol rules for all operations

2. Reserved Resources:

   • Reserved namespaces for official use (.redd, etc.)
   • Protected identifiers for system operation
   • Trademark protection mechanisms

3. Protocol Evolution:

   • System upgrade processes
   • Feature addition procedures
   • Backward compatibility requirements

4. Security Response:

   • Vulnerability reporting and handling
   • Emergency response procedures
   • System integrity protection

Namespace owners have governance rights over their namespace:

1. Configuration Authority:

   • Character rule definition
   • Length requirements
   • Pricing tier configuration
   • Revenue distribution within allowed ranges
   • ReddID registration and renewal fee settings

2. Operational Control:

   • User ID auction approvals (optional)
   • Premium name designation
   • Namespace-specific renewal policies
   • Usage discount configuration

3. Namespace Evolution:

   • Configuration update procedures
   • Feature enabling/disabling
   • Service integration options

4. First-Level Dispute Resolution:

   • Preliminary trademark disputes
   • Name squatting complaints
   • Usage policy enforcement

A comprehensive framework for handling disputes includes:

1. Dispute Categories:

   • Identity ownership disputes
   • Trademark and brand claims
   • Impersonation claims
   • Verification challenges
   • Usage policy violations

2. Resolution Process:

   • Initial automated assessment
   • Peer-based review for standard cases
   • Expert panel for complex disputes
   • Binding arbitration for unresolvable cases

3. Enforcement Mechanisms:

   • Warning notifications
   • Temporary suspensions
   • Permanent revocations (extreme cases)
   • Economic penalties
   • Profile flags and indicators

4. Appeal Process:

   • Multi-level appeals
   • Community oversight
   • Transparent decision documentation
   • Review mechanism for disputed decisions

1. Cross-Component Integration:

   • Seamless data flow between all system components
   • Consistent interfaces and formats
   • Unified event handling
   • Integrated state management

2. Core Protocol Services:

   • Integration with Reddcoin staking system
   • Compatibility with ReddPay payment services
   • Support for smart contract interactions
   • Identity-based transaction authorization

3. Application Ecosystem:

   • Standard API for third-party applications
   • SDK for developers to integrate identity functions
   • OAuth-style authentication support
   • Webhook notification system

1. Cross-Chain Resolution:

   • Resolution protocol for external blockchain identifiers
   • Bridge contracts for Ethereum, Binance Smart Chain
   • Verifiable claims for cross-chain identity
   • Inter-chain message passing

2. Web Standards Compatibility:

   • W3C DID (Decentralized Identifier) compatibility
   • Verifiable Credentials support
   • WebAuthn integration options
   • OAuth/OpenID Connect bridge

3. Legacy System Integration:

   • Email-based verification processes
   • API gateway for traditional systems
   • Progressive migration paths
   • Hybrid identity solutions

The system exposes a comprehensive API:

1. Core Endpoints:

   • /namespace/* - Namespace management endpoints
   • /userid/* - User ID management endpoints
   • /reddid/* - ReddID profile and social endpoints
   • /auction/* - Auction interaction endpoints
   • /reputation/* - Reputation data endpoints

2. Authentication Methods:

   • Signature-based authentication
   • Challenge-response protocol
   • Delegation capabilities
   • Session management

3. Data Formats:

   • JSON primary representation
   • Compact binary format for bandwidth-constrained environments
   • Verifiable credential format option
   • IPFS content addressing

• System Architecture Diagram
• Database Entity Relationship Diagram
• P2P Protocol Message Flow
• Auction System Flow Chart
• Namespace Integration Diagram
• Reputation Calculation Model
• Cross-Namespace Resolution Diagram
• Social Connection Model

• Namespace Auction Browser Interface
• User ID Auction Browser Interface
• ReddID Registration Interface
• Bid Placement Interface
• User Dashboard
• Identity Profile Manager
• Social Dashboard
• Mobile Interface Concepts

• Namespace Valuation Analysis
• User ID Price Discovery Simulation
• Revenue Distribution Model
• Renewal Economics Study
• Anti-Squatting Effectiveness Model
• Reputation Economic Impact Study
• ReddID Fee Structure Analysis

• Detailed Code Samples
• API Specifications
• Testing Frameworks
• Namespace Integration Guide
• ReddID Integration Guide
• Verification Procedures
• Governance Procedures