PresenceNet Protocol

Protocol Overview

Core Primitives

PresenceNet is made up of five interoperable primitives for verifying and coordinating presence:

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 keeps marking accessible to everyone
• 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
• Erasable content: Mark contents are encrypted with keys each person controls. Destroying the key permanently erases the content, while the proof of presence remains on-chain.

Trails

A Trail is an append-only ledger of all marks associated with a $handle — a continuous, user-controlled record of presence over time.

Trail Properties

• Private by design: Mark contents are encrypted by default. Transaction metadata lives on the public XRP Ledger.
• 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 explicit, 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
• Durable: Stored on IPFS/Arweave for long-term persistence

Use Cases

Role Tags (•tag)

Role Tags are cryptographically verifiable, temporary roles for vaults, DAOs, and rituals. They replace static permissions with temporary, 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 encryption model follows the shape of real trust relationships — individual, bilateral, and group — so access maps to how people actually coordinate.

Three Trust Geometries

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",
  invited_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