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.
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)
Add & Encrypt
In Share Your Keys, paste the upstream API key and click Encrypt. Encryption happens client-side; only ciphertext is stored.
Set Policy
Configure allowed models/regions, concurrency and daily caps, and effective/expiry windows for that key.
Activate the Channel
Toggle Activate. The scheduler may select your channel when it meets policy and performance criteria.
Execute & Receipt
On selection, the executor decrypts in a secure environment, calls the upstream API, and emits structured usage and price logs.
Accrue Rewards
View period-based earnings in the Console; export detailed line-items at any time.
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
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
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：
Last updated