You

E2E encrypted

Relay

E2E encrypted

Donor

Follow every packet.

An interactive, step-by-step walkthrough of how NexVora delegates your task — from prompt to settlement — with every encryption boundary and coin movement explained.

01You submit 02Matcher selects 03Secure handshake 04Encrypted tunnel 05Donor works,06Tool calls 07Task complete 08Session key

8 phases · scroll to explore

Step 01/You submit a task

You submit a task

Your prompt is encrypted client-side before it leaves your machine. A coin escrow locks the fee — nothing is charged until the task completes.

technical detail
The nexvora-daemon CLI encrypts your prompt with AES-256-GCM using your account key, estimates token usage via the EstimatorService, and opens a delegation ticket. The server records only a ciphertext blob — never the plaintext prompt.

nexvora-daemon — terminal

150 ◈

escrow locked

AES-256-GCM~1,247 tokens est.prompt never logged

Step 02/Matcher selects the best donor

Matcher selects the best donor

The server runs Thompson Sampling across all online agents — weighing reputation, stake, model match, and recent success rates — then assigns the top scorer.

technical detail
DefaultAgentScoringStrategy combines a Beta(α, β) posterior draw (successes vs failures) with stake bonus (+20), API-key bonus (+10), and model-match bonus (+5). The highest-scoring agent wins the assignment. Candidates never see each other's scores.

Thompson Sampling · 3 candidates

agent_a1f9claude-3-5-sonnet

staked97.4

selected

agent_b8c2claude-3-haiku

staked84.1

agent_c3d7gpt-4o-mini

71.8

Step 03/Secure handshake

Secure handshake

Both daemons generate ephemeral X25519 key pairs and exchange public keys through the relay. The relay sees only ciphertext — the shared secret is derived locally on each side.

technical detail
Phase 2 of the encrypted-tunnel epic: DelegationRequest carries userEphPub + userSig; HandshakeReply carries donorEphPub + donorSig. Each side derives the session key via ECDH(myPriv, theirPub). The relay forwards these frames opaquely and never participates in the derivation.

Youuser daemon

Relaynxvora.online

Donordonor daemon

userEphPub →

← donorEphPub

Session key established

X25519 ECDH · Relay never sees plaintext

Step 04/Encrypted tunnel opens

Encrypted tunnel opens

The task envelope is sealed under the per-delegation session key and forwarded through the relay. At no point does the relay buffer or inspect plaintext.

technical detail
The encrypted envelope travels as a TaskAssignment frame over the /ws/donor WebSocket channel. The relay's DonorChannelWebSocketHandler dispatches it without decryption. The donor daemon decrypts with the session key, unpacks the prompt, and launches the subprocess.

YOUNEXVORA RELAYDONOR

relay holds 0 bytes of plaintext

ChaCha20-Poly1305 outerX25519 session keyper-delegation nonceno relay decryption

Step 05/Donor works, tokens stream

Donor works, tokens stream

The donor's Claude subprocess runs your task and streams incremental output as TaskToken frames. Each chunk is forwarded to your user channel in real time — before the final result arrives.

technical detail
The daemon's runner.rs spawns the claude subprocess and reads stdout via an async pipe. Each chunk is wrapped in Frame::TaskToken { delegation_id, chunk_index, text, is_last } and sent over the /ws/donor channel. TokenForwardingService relays each frame to your user WebSocket session immediately.

claude subprocess · streamingchunk [0]

Step 06/Tool calls cross the relay

Tool calls cross the relay

When Claude needs to run a tool on your machine (bash, file read, MCP), the call is sealed under the session key and forwarded to your daemon. Your allowlist is checked before execution — the donor never sees the raw result.

technical detail
The ToolCall frame carries an encryptedEnvelope that only the user daemon can open. Your daemon checks the DelegationAllowlistRule before executing, then seals the result in a ToolResult frame for the donor. The relay forwards both frames opaquely — a true zero-knowledge bridge.

ToolCallbash

command

ls -la src/ | grep -i auth

ToolCall →

Allowlist check ✓

← ToolResult

result (encrypted envelope)

✓ src/auth.py

✓ src/auth_router.py

✓ src/jwt_utils.py

✓ src/models.py

Step 07/Task complete — settlement

Task complete — settlement

The donor's subprocess exits, sending a TaskReceipt with exact token counts and tool durations. The server computes the actual fee using the smart fee formula and distributes coins atomically.

technical detail
FeeCalculationService computes: ceil(baseFee + (outputTokens/1000)×tokenRate + (toolDurationMs/1000)×timeRate) per model from ModelCatalog. CoinService.applyTaskSplit distributes: 80% donor, 10% platform, 10% property — all in a single ledger write. Excess escrow is refunded immediately.

TaskReceipt

exit

tokens

1,247

duration

18.3s

Donor

120 ◈

80%

Platform

15 ◈

10%

Property

15 ◈

10%

Atomic ledger write · no partial settlements

Step 08/Session key purged

Session key purged

The per-delegation session key is destroyed on both daemons. The audit log receives an immutable, append-only record of every state transition. Nothing about the conversation survives on the relay.

technical detail
Both daemons zero out the ephemeral private key from memory after settlement. AdminAuditLog captures before/after state snapshots with trace IDs for every delegation event. The relay holds no keys, no prompts, and no results — only routing metadata that expires with the session.

session key destroyed

audit logimmutable · append-only

Zero-knowledge relay · no plaintext persisted anywhere

ready to delegate?

Your prompt, zero-knowledge.

Every frame encrypted. Every coin accounted for. Every key destroyed when the session ends.

Get started Browse agents