Nodes

Every entity in the ƒxyz network exists as a validated node with temporal relationships, privacy controls, and dynamic properties. The Knowledge Graph represents three primary node types, each with distinct capabilities and roles within the ecosystem.

Node Types

Human Nodes

Individuals and entities with decentralized identities, multi-chain wallets, and dynamic reputation systems.

Identity & Authentication

• DIDs: Decentralized identifiers for sovereign identity
• Linked Wallets: Multi-chain wallet connections (Solana, Ethereum, Bitcoin)
• Dynamic Certificates: Reputation tokens that evolve with network contributions
• KYC/KYB Verification: Third-party verification via Bridge.xyz (no PII stored on-network)

Reputation & Validation

• Peer Validation: Community-driven verification processes
• Behavioral Tracking: Positive/negative attributes through graph relationships
• Historical Analysis: Temporal transaction patterns and activity tracking
• Network Participation: Contribution weight and influence in network decisions

Fixies (Digital Agents)

Autonomous AI agents that operate across the network with specific capabilities and permissions.

Agent Types

• Member Fixies: Personal agents assigned to individual members with private data access
• Project Fixies: Agents scoped to specific projects or circles within the network
• Network Fixies: System-level agents for network-wide operations and monitoring

Capabilities

• Graph Observation: Pattern detection and anomaly identification
• Data Validation: Cross-reference verification and consistency checking
• Privacy Management: User data sharing controls with granular permissions
• Learning & Adaptation: Continuous improvement through interaction patterns

Financial Entities

Institutional nodes representing traditional and digital financial infrastructure.

Institution Types

• Banks: Traditional and digital banking entities with API integrations
• Venues: Centralized and on-chain liquidity venues
• Stablecoin Issuers: USDC, USDT, and other stable value token providers
• Central Banks: CBDC issuers and monetary policy entities

Network Integration

• API Connections: Real-time data feeds for rates and liquidity
• Liquidity Provision: Market making and arbitrage opportunities
• Compliance Monitoring: Regulatory adherence and reporting
• Risk Assessment: Credit scoring and counterparty analysis

Regulatory Licenses

License and authorization nodes tracking the network's compliance infrastructure across jurisdictions.

License Types

• CASP: Crypto-Asset Service Provider authorization under MiCA (Classes 1-3)
• PI: Payment Institution license under PSD2 (fiat payment processing)
• EMI: Electronic Money Institution under EMD2 (e-money token issuance)
• MIFID: MiFID II Investment Firm authorization (derivatives and securities)

License Properties

• Jurisdiction: Geographic scope of authorization (EU member state, national)
• Status: PLANNED, APPLIED, PENDING, GRANTED, ACTIVE
• Capital Requirements: Minimum own funds and prudential buffers
• Phase: Strategic implementation phase (Phase 1, 2, or 3)

License Relationships

• HOLDS_LICENSE: Links LegalEntity to RegulatoryLicense
• OVERSEES_LICENSE: Links governance Circle to license compliance
• FUNDS_LICENSE: Links InvestmentRound to capital requirements for specific licenses

Node Roles & Permissions

Access Control

Node permissions are managed through an ACL (Access Control List) system with tiered privacy controls. Permissions cascade from node-level ACLs to circle-level property ACLs, with tier-based privacy as the fallback.

Contribution levels (canonical 5-tier ladder, CES-derived for the middle 5; see canon §3 + §15):

• OBSERVER — default for any account that has not yet earned a score; basic read access to public graph data.
• INITIATE — entry tier; transaction and interaction capabilities unlock.
• EXPLORER — first CES-derived contribution level; broader read on circle-gated content.
• NAVIGATOR — meaningful, sustained contribution across active layers; peer-vouching and validation weight.
• FOUNDER — top contribution tier; governance proposal creation, allocation weight, role eligibility.

The bottom three (GHOST, GUEST, OBSERVER) are derived from the standing logic; the middle four (INITIATE / EXPLORER / NAVIGATOR / FOUNDER) are CES-derived. FOUNDING_GUARDIAN is a manually-assigned co-founder display label that combines FOUNDER tier weight with elevated standing — there is exactly one founder so it's a unique display label, not a separate CES tier.

Planned Enhancements

The following permission capabilities are in development:

• Reputation-Based Thresholds: Access levels that adjust based on network reputation (design phase)
• Skill-Based Roles: Specialized permissions for specific capabilities
• Collective Validation: Community-verified role assignments

Privacy Architecture

Public Layer

Information visible to the network and external observers:

• Reputation score and public achievements
• Public transaction history (non-confidential)
• Governance votes and participation
• Knowledge contributions and validations

Private Layer

Information controlled by individual nodes through Fixie agents:

• Confidential token balances (ElGamal encrypted)
• Private network membership and communications
• Sensitive transaction details and relationships
• Personal agent data and preferences

Member node — actual shape

Member nodes are described by a Privy-issued did (did:privy:...), a magnitudeClass (Harvard 7-class — see canon §4), standing, contributionLevel (the 5-tier ladder above), and a score (CES synthesis). Real names and personal emails never live on the node — the public identifier is the assigned star name (IAU catalog), not the DID. Wallets link to the member via (:Member)-[:OWNS_WALLET]->(:Wallet) edges; on-chain balances are read live from Solana, not stored as Neo4j properties.

For the live shape, see packages/types/src/member.ts and the Member-related Cypher patterns in Cypher Examples. For PII handling, see .claude/rules/pii-rules.md.

Relationship Types

Financial Relationships

• VALIDATES: Peer validation and verification
• HOLDS: Token balances and asset ownership
• TRANSFERS: Transaction relationships with temporal data
• PROVIDES_LIQUIDITY: Market making and exchange facilitation

Governance Relationships

• PARTICIPATES_IN: Network and DAO participation
• ENDORSES: Peer recommendations and reputation
• PROPOSES: Governance proposal creation and sponsorship
• VOTES_FOR/AGAINST: Decision participation with weight

Knowledge Relationships

• CONTRIBUTES: Knowledge base additions and improvements
• REVIEWS: Peer review and validation activities
• LEARNS_FROM: Educational relationships and mentorship
• TEACHES: Knowledge transfer and skill development

Dynamic Relationship Evolution

Every interaction, transaction, and governance action creates temporal relationships in the knowledge graph. On-chain token operations are recorded on Solana with native timestamps. This enables:

• Historical Analysis: Understanding how relationships evolved over time
• Trend Detection: Identifying patterns in node behavior and network growth
• Causal Inference: Determining cause-effect relationships in network events
• Predictive Modeling: Forecasting node evolution and network development

Implementation Notes

• Graph Writes: Node mutations are stored in Neo4j with timestamps; on-chain operations are recorded on Solana
• Privacy Controls: ACL-based data visibility with Fixie agent management per user preferences
• Reputation Updates: Calculation based on weighted peer endorsements
• Role Advancement: Validation through network protocols and governance circles

The node system creates a rich, dynamic representation of the ƒxyz network that balances transparency with privacy, enabling sophisticated financial operations while maintaining decentralized governance.