Quickstart & Client Onboarding

Step 1: Install Your Client Application

Choose the client application suited to your environment. All official clients share identical OpenAPI schemas, token palettes, and state machine transitions:

For headless server nodes or automated trading bots, you can also interact directly with the REST API using curl or any HTTP client library.

Step 2: Sponsor Lineage Activation Code

NodeHash enforces Sybil resistance through social collateral rather than energy-wasting Proof of Work puzzles or intrusive surveillance databases. Every newcomer must supply a valid sponsor invite code during initial registration.

The network calculates sponsor accountability through a geometric damping formula capped at three hops:

factor(depth) = 0.5^(depth - 1)  where depth in {1, 2, 3}

• Hop 1 (Direct Sponsor): Absorbs 100% of downstream dispute impact.
• Hop 2 (Grand-Sponsor): Absorbs 50% of downstream dispute impact.
• Hop 3 (Great-Grand-Sponsor): Absorbs 25% of downstream dispute impact.
• Depths > 3: Completely decoupled, containing risk from spreading across the global network.

Step 3: Cryptographic Passkey Registration

When you create an account, the client calls your device's hardware chip to generate a dedicated P-256 elliptic curve keypair. The client stores the private key inside the hardware enclave and sends the public key, your user handle, and your sponsor code to the registration endpoint.

Here is a realistic registration request using curl:

curl -X POST http://localhost:3000/api/v1/auth/register \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Elena Rostova",
    "email": "elena@example.com",
    "password": "SecureEnclavePasskeyHash89!",
    "sponsor_code": "SPONSOR-NODE-9842",
    "bio": "Distributed systems engineer and UI prototyper",
    "location": "Berlin, Germany"
  }'

The server verifies the sponsor code, records your initial trust score (defaulting to 100 points), and returns JWT authentication tokens:

{
  "success": true,
  "data": {
    "user": {
      "userId": "usr_9f81a7b4c2",
      "name": "Elena Rostova",
      "email": "elena@example.com",
      "inviter_id": "usr_sponsor_9842",
      "reputation_profile": {
        "trust_score": 100,
        "completed_exchanges": 0,
        "fulfillment_rate": 1.0
      },
      "credit_account": {
        "current_balance": 0,
        "unsettled_credit_limit": 500
      }
    },
    "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "refreshToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  }
}

Step 4: Configure Bidirectional Profiles

NodeHash requires every participant to declare both supply and demand. In a mutual barter graph, pure consumers drain liquidity without replenishing it, while pure suppliers cannot close cycles. Cycle detection algorithms need directed edges in both directions to discover 2-party and 3-party closed loops.

Your account maintains two parallel portfolios:

• Supply Profile (supply_profile): Skills, compute services, or deliverables you offer to the network.
• Demand Profile (demand_profile): Capabilities, tools, or services you want in return.

Each item requires an item ID, a Tier 1 primary tag, up to ten Tier 2 sub-tags, and a weekly availability schedule.

Registering Supply and Demand Items

Submit your items to POST /api/v1/exchange/register:

curl -X POST http://localhost:3000/api/v1/exchange/register \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1Ni..." \
  -d '{
    "supply_items": [
      {
        "itemId": "sup_ts_backend_01",
        "primary_tag": "software-dev",
        "sub_tags": ["typescript", "node.js", "graphql"],
        "proficiency": 5,
        "description": "Backend API engineering and graph database schema design",
        "temporal": {
          "time_zone": "Europe/Berlin",
          "available_time_windows": [
            {
              "day_of_week": 1,
              "start_time": "09:00",
              "end_time": "17:00",
              "is_negotiable": true
            },
            {
              "day_of_week": 3,
              "start_time": "09:00",
              "end_time": "17:00",
              "is_negotiable": true
            }
          ]
        }
      }
    ],
    "demand_items": [
      {
        "itemId": "dem_ui_design_01",
        "primary_tag": "design",
        "sub_tags": ["ui-design", "figma", "design-systems"],
        "priority": 4,
        "urgency": "high",
        "temporal": {
          "time_zone": "Europe/Berlin",
          "available_time_windows": [
            {
              "day_of_week": 2,
              "start_time": "10:00",
              "end_time": "18:00",
              "is_negotiable": true
            }
          ]
        }
      }
    ]
  }'

Once submitted, the backend validates your tags against the taxonomy tree and activates your items in the inverted candidate index.

Step 5: Candidate Discovery & Cycle Matching

As soon as your items enter active candidate pools, the cycle engine searches for closed barter loops. To run an immediate cycle discovery pass, call the matching endpoint:

curl -X POST http://localhost:3000/api/v1/exchange/match \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1Ni..."

Matching identifies both bilateral pairs (Alice provides TypeScript to Bob, Bob provides Design to Alice) and trilateral loops (Alice provides TypeScript to Bob, Bob provides DevOps to Charlie, Charlie provides Design to Alice). Unmatched supply items remain active in the pool for subsequent discovery passes.