# BYOK（Bring Your Own Keys）

### Architecture

* Provider Console (Share Your Keys): Add / encrypt / activate your upstream API key(s); set allowed models, regions, and quotas.
* Encryption & Ciphertext Store: Keys are encrypted in the browser before submission. The platform stores only ciphertext and metadata (revocable/expirable).
* Executor: When a task is assigned, the ciphertext is decrypted inside a secure environment (e.g., TEE, depending on the route), used briefly in memory, then wiped—no disk writes.
* Scheduler: Chooses whether to route traffic through your key based on price, latency, availability, and policy weights.
* Billing & Audit: Tracks actual usage and generates period snapshots; export line-items for local reconciliation.<br>

Data flow (simplified):

Add Key → Client-side Encrypt → Submit Ciphertext → Activate + Policy → On Hit: Decrypt in Secure Env → Logs & Usage → Billing & Payout.

### How It Works (Step by Step)

1. Add & Encrypt

   In Share Your Keys, paste the upstream API key and click Encrypt. Encryption happens client-side; only ciphertext is stored.
2. Set Policy

   Configure allowed models/regions, concurrency and daily caps, and effective/expiry windows for that key.
3. Activate the Channel

   Toggle Activate. The scheduler may select your channel when it meets policy and performance criteria.
4. Execute & Receipt

   On selection, the executor decrypts in a secure environment, calls the upstream API, and emits structured usage and price logs.
5. Accrue Rewards

   View period-based earnings in the Console; export detailed line-items at any time.
6. Pause / Rotate Anytime

   You can Deactivate or replace the ciphertext (key rotation) at will—policies take effect immediately.

### Why Share Your Key

* Monetize existing limits: Convert idle or surplus upstream quotas into revenue.
* Capture price/region advantages: Some accounts perform better by region/time; the scheduler prefers higher value routes.
* Low ops, passive yield: No inference hosting—just set policies and rotate keys when needed.
* Revocable & risk-controlled: Pause anytime, set quotas/whitelists, and tightly bound usage scope.
* Transparent & auditable: Downloadable bills and snapshots for independent verification.

### Security & Privacy

Goal: Under a “platform zero-trust” assumption, minimize key exposure across its lifecycle, strictly bound scope, and ensure verifiable auditability.

#### 1) No plaintext exposure (client-side encryption; platform cannot decrypt)

* Uses X25519 (key agreement) + ChaCha20-Poly1305 (AEAD).

  The Provider generates a temporary keypair locally, derives a shared secret with the target executor’s public key, and encrypts the API key locally before upload.
* The backend stores only ciphertext and metadata (e.g., nonce, tag, ephemeralPubKey, status/createdAt) and never sees plaintext.
* Decryption occurs only at the executor. Gateway/backend lack decryption capability. Each encryption uses an independent ephemeral keypair for forward secrecy.

#### 2) Minimal exposure window (in-memory, ephemeral)

* Executors load private keys from a Secret Manager at startup.

  Before execution, they pull ciphertext (e.g., from etcd), reconstruct the shared secret, decrypt in memory, execute, then zeroize memory; no disk writes.
* Operational logs store summaries only (no plaintext, no keys).

#### 3) Scoped access & policy control

* Restrict key scope by provider / region / model. Separate executors use independent keypairs/sessions to limit lateral risk.
* Enforce concurrency/day caps/effective windows/whitelists. Auto downgrade or evict a route on anomaly thresholds.

#### 4) Rotation & expiry (TTL)

* One-click key rotation supported; TTL can auto-expire usage windows. Optional alerts and risk controls on balance/ban/anomalous usage.

#### 5) Transport & integrity

* TLS end-to-end. Ciphertext uses AEAD (nonce+tag) for integrity. Critical metadata is signed for tamper detection.

#### 6) Audit & verification

* Every call writes structured usage records. Periodically, we build a Merkle tree and publish a snapshot.

  Providers can download statements and proofs to locally verify profit-shares and source lineage.

#### 7) Threat model&#x20;

* Database leak: Attackers obtain only ciphertext/metadata—no decryption possible.
* Single executor compromise: Scope/TTL/session isolation limits blast radius; executor keys live in Secret Manager and can be rotated; you can pause channels and revoke ciphertext.
* In-transit interception/tamper: TLS + AEAD preserves confidentiality/integrity; signed metadata flags anomalies.

## Rewards & Payouts

Provider rewards are based on your self-defined baseline price P and actual token usage T.

For detailed per-model pricing, see Model Price.

providerReward = P × T × rewardRate\
protocolFee = P × T × feeRate

* Reward rate: Your revenue share percentage, applied to the billable usage (pricePerToken × actual tokens hit).
* Pricing & policies: You can set different P (price per token) by model/region, plus concurrency, daily caps, and start/stop windows. The router will select your channel when it meets performance and policy constraints.
* Multi-segment routing: A single request may be split across multiple providers; rewards accrue per segment and are summed.

\
Settlement Cycle & Verification

* Periodic snapshots: For each cycle, we generate a settlement Snapshot containing:
  * Hash of every usage record within the window,
  * The price table used for billing,
  * A summarized Merkle Root.
* Self-verification: Download line-items and proofs to locally reconstruct and verify your expected payout.
* Payouts: Once you pass the minimum threshold, you can request settlement (fiat/stablecoin/platform balance—see Console for options).

### Example

If this period your key served 1,000,000 output tokens at $0.40 per 1k tokens and your rewardRate = 90%:

* Billable amount: P × T = $0.40/1k × 1,000k = $400
* Your reward: providerReward = $400 × 0.90 = $360

### Points&#x20;

In addition to cash revenue share, you may also receive campaign points/subsidies during certain periods (subject to the then-current program rules).  Please Refer to：