PresenceNet Protocol

Protocol Overview

Core Primitives

PresenceNet consists of five interoperable primitives that compose a complete system for verifying and coordinating human conscious experience:

Marks

A Mark is the fundamental unit of presence in PresenceNet. Each mark is a cryptographically signed, timestamped transaction on the XRP Ledger that costs 0.00001 XRP.

Mark Schema

{
  "markId": "uuid-or-cid",
  "version": "1.0",
  "timestamp": "2025-01-15T18:00:00Z",
  "witness": "$alice",
  "markType": "ritual",
  "note": "Completed Circle Ritual",
  "ritual": {
    "ritualId": "circle_2025",
    "participants": ["$alice", "$bob", "$mira"],
    "threshold": 3
  },
  "signature": "0xabc123..."
}

Mark Types

• Self Mark: Personal reflection or commitment, witnessed by $witness
• Ritual Mark: Participation in a structured coordination pattern
• Vault Mark: Signature for multi-sig vault operations
• Public Mark: Openly witnessed presence at an event or moment

Properties

• Minimal Cost: 0.00001 XRP ensures accessibility (1 billion marks = ~$100 in fees)
• Cryptographically Verified: Ed25519 signatures ensure authenticity
• Encrypted Memos: Optional AES-256 encrypted payloads for privacy
• Immutable: Once on XRPL, marks cannot be altered or deleted

Trails

A Trail is an append-only, sovereign ledger of all marks associated with a $handle. Trails form continuous narratives of presence, enabling identity to emerge through memory rather than external validation.

Trail Properties

• Private by Default: Only you control visibility of your trail
• Portable: Trails can be exported and synced across applications
• Verifiable: Cryptographic proofs enable selective disclosure
• Weighted: Trail weight accumulates through ritual completions

Trail-Based Logic

Rituals and Vaults use trail-based conditions to govern access:

{
  "required_trail_depth": 30,
  "required_marks": ["ritual_presence", "vault_signature"],
  "mark_recency_window": "30d",
  "requires_completion_of": ["initiation_2025"],
  "custom_boolean_expression": "trail_weight >= 100"
}

Trail Indexing

Trails are indexed for efficient querying while preserving privacy:

• On-Chain: Mark transactions stored on XRPL
• Off-Chain Index: Metadata indexed in Firestore/IPFS
• Encrypted Content: Memo payloads encrypted client-side
• ZK-Proof Compatible: Future integration for trail verification without exposure

Rituals

Rituals are structured coordination patterns that define how presence is verified and coordinated. They replace static rules with sacred, action-bound signals.

Ritual Object Schema

Each ritual is defined by a comprehensive schema covering identity, timing, participants, eligibility, and outcomes:

{
  "ritual_id": "circle_2025",
  "ritual_version": "1.0",
  "ritual_archetype": "circle",
  "host_handle": "$mayowa",
  "invited_handles": ["$alice", "$bob", "$mira"],
  "start_time": "2025-06-01T18:00:00Z",
  "end_time": "2025-06-01T20:00:00Z",
  "required_mark_target": "$mayowa~presence",
  "completion_condition": "minimum_marks: 3",
  "linked_chamber": "vault:creativevault",
  "biometric_required": false,
  "recurring": false
}

Ritual Archetypes

Ritual Mechanics

Rituals can exhibit transformative behaviors:

• Recursion: Auto-restart (e.g., weekly circle)
• Mutation: Morph into another ritual upon completion
• Replication: Spawn clones for new participants
• Merge: Combine multiple rituals into one
• Decay: Invalidate if not completed in time
• Sealing: Lock after N completions

Example Rituals

Vaults

Vaults are multi-signature XRPL wallets governed by presence-based rules rather than token ownership. They integrate with rituals to enable dynamic, behavior-bound access control.

Vault Integration Modes

Example: DAO Governance Vault

{
  "vault_id": "dao_treasury",
  "signers": ["$alice", "$bob", "$mira"],
  "threshold": "2/3",
  "governance_ritual": "circle_of_consensus_2025",
  "role_requirements": {
    "•signer": {
      "grant_condition": "trail_weight >= 100",
      "issuance": "ritual-issued"
    }
  }
}

In this setup, ritual completion grants •signer tags dynamically. Only those with active tags can sign vault transactions.

Chambers

Chambers are sealed memory containers created by advanced rituals. They preserve symbolic content (text, media, NFTs) accessible only to participants who completed the ritual.

Chamber Properties

• Private: Only ritual participants can access
• Immutable: Content cannot be altered after sealing
• Trail-Gated: Access requires proof of ritual completion in trail
• Eternal: Stored on IPFS/Arweave for permanence

Use Cases

Role Tags (•tag)

Role Tags are cryptographically verifiable, temporary roles for vaults, DAOs, and rituals. They replace static permissions with sovereign, action-bound signals.

Tag Properties

• Optional: Self-claimed or ritual-issued; no defaults
• Temporary: Burned after expiry or ritual completion
• Contextual: Valid only in specific vault/ritual scope
• Revocable: Auto-burned if revocation conditions met
• Composable: Stack with ~suffix (e.g., $alice~delegate•voter)

Tag Schema

{
  "roles": {
    "•signer": {
      "threshold": "3/5",
      "grant_condition": "trail_marks >= 100",
      "issuance": "self-claimed",
      "expiry": "30d"
    },
    "•voter": {
      "grant_condition": "ritual:governance_complete",
      "issuance": "ritual-issued",
      "revoke_conditions": {
        "•banned": "hostile_marks >= 3"
      }
    }
  }
}

Tag Lifecycle

1. Grant: Earned via trail depth, ritual completion, or self-claim
2. Use: Tag enables vault signatures, voting, or access
3. Revoke: Expired, ritual-triggered, or consensus-based removal
4. Burn: Tag destroyed on-chain, recorded in trail

Trust Geometry

PresenceNet's cryptographic architecture mirrors the natural geometry of human trust relationships. Rather than forcing relationships through digital abstractions, we build tools that respect covenant formation.

Three Trust Geometries

Covenant vs Contract

A covenant is a voluntary act of alignment carrying moral or sacred significance. Unlike contracts (enforced externally), covenants are honored internally. PresenceNet encodes the geometry of trust in a way that respects human relationships.

"This is the first cryptographic system where the mathematical structure of encryption directly mirrors the mathematical structure of human trust relationships."

Implementation Guide

PresenceNet is built on the XRP Ledger with additional infrastructure for trails, rituals, and chambers.

Technical Stack

• Blockchain: XRP Ledger (XRPL) for mark transactions
• Storage: IPFS/Arweave for chambers and trail archival
• Indexing: Firestore for trail metadata and ritual state
• Encryption: AES-256 for memos, Ed25519 for signatures
• SDK: JavaScript, Dart, Rust implementations

Developer Quickstart

// Define a ritual
const ritual = {
  ritual_id: "starter_circle_2025",
  ritual_archetype: "circle",
  host_handle: "$dev",
  participant_handles: ["$alice", "$bob"],
  start_time: "2025-06-01T10:00:00Z",
  end_time: "2025-06-01T12:00:00Z",
  required_mark_target: "$dev~presence",
  completion_condition: "minimum_marks: 2"
}

// Submit to PresenceNet
await createRitual(ritual)

// Submit a mark
await submitMark({
  from: "$alice",
  to: "$dev~presence",
  ritual_id: "starter_circle_2025"
})

// Check trail
const trail = await checkTrail("$alice")
console.log(trail.weight) // Trail weight

Privacy Architecture

• Encrypted by Default: Mark memos use AES-256 encryption
• Proxy Routing: $handle-to-$handle transactions route through proxies
• Mutual Contacts: Rituals restrict access to verified $handles
• ZK-Proof Compatible: Future integration for trail verification without exposure

Resources