01 KRAPH 02 SECURE AI CLOUD 03 BUILD HOST PROTECT

Q. How is this different from Vercel or Supabase?

Vercel and Supabase are strong hosted developer platforms. Kraph targets the same shipping loop (frontend + backend + auth + data), but adds Forge + MCP for AI-native workflows, x402 USDC metering for autonomous provisioning, a node operator network, and a confidential-production posture: encrypted secrets at rest, encrypted WAL replication, and SEV-SNP attested placement on eligible mainnet nodes. Kraph orchestrates the open-source Supabase stack for compatibility, but it is an independent project — not affiliated with Supabase Inc.

Q. What is Forge?

Forge is Kraph’s in-browser builder: a Lovable/Base44-style way to iterate on an AI app while targeting the same Postgres, Auth, Storage, Functions, and secrets surface you get from the network. You can open it at forge.kraph.com/build.

Q. Is Kraph a Supabase competitor?

Kraph is not Supabase, but it is Supabase-compatible by orchestrating the same open-source components many teams already use. The differentiation is the bundle: AI builder + agent provisioning + stablecoin-metered tool calls + encrypted replication + decentralized placement + attested hardware options.

Q. Can Kraph or node operators read my API keys and secrets?

Function secrets are encrypted at rest on the node and applied to the runtime when needed. On mainnet SEV-SNP nodes, the design goal is for plaintext to exist only inside the attested enclave during apply, not for operators to read from ordinary host memory. On devnet, assume operators could observe values during brief decrypt windows — devnet is for iteration, not confidentiality. Separately, the gateway remains part of the trust model for orchestration and some tooling paths; see the whitepaper for details.

Q. How is this different from Lovable, Base44, or other app builders?

Tools like Lovable and Base44 excel at fast UI generation. Kraph adds Forge for that builder-style flow, then backs it with the same production stack you get from the network: Postgres, auth, realtime, storage, edge functions, encrypted secrets, optional x402 USDC metering via MCP, encrypted replication, and independent operator nodes — not only a generated front end.

Q. What about Lindy, Zapier Agents, n8n, or enterprise agent platforms?

Workflow tools excel at triggers and SaaS glue. Kraph gives each workload a Supabase-compatible stack you control — Postgres, functions, storage, auth — plus decentralized placement and optional AMD SEV-SNP attestation on mainnet-tier nodes. Pick kraph when the agent needs its own database and server logic, not only chained steps.

Q. Can I bring my own LLM API keys?

Yes — that’s the default path for backend and functions: store keys in function-scoped secrets via kraph_set_env, never in prompts; grant each tool the minimum access it needs and rotate keys on a schedule. Forge is adding BYO provider keys for people who want Claude, OpenAI / Codex, or compatible endpoints instead of the built-in assistant. Optional hosted inference from kraph may arrive later for teams who want one invoice — it is not required today.

Q. How are API keys and third-party tokens protected?

Use function-scoped env vars via kraph_set_env — encrypted at rest on the node. On mainnet SEV-SNP nodes, plaintext only exists briefly inside the attested enclave when applied to the runtime. Still follow least privilege: rotate keys, scope tools, and audit what each agent is allowed to call.

Q. Can an existing app or agent use Kraph?

Yes. Kraph is the backend and hosting layer: you connect your app, automation, or agent tooling to the provisioned URLs and keys. Today you typically wire provisioning through MCP (kraph_provision) or build with Forge; swap env vars and SDK endpoints like any Supabase-shaped project.

Q. Do I need crypto as an end user?

Public end users may not need crypto later if you ship hosted billing on top. Developers using MCP today use a Solana wallet (or Privy) so USDC can settle x402 invoices for paid tools — that’s the crypto touchpoint now. Hosted billing products may abstract wallets so day-to-day users never manage one while the protocol stays underneath.

Q. How do node operators get paid?

Approved operators receive monthly USDC vendor payments for verified infrastructure — compute, storage, bandwidth, uptime, region, and attestation tier where applicable. Commercial terms include a platform fee and service-level adjustments when agreed targets are not met. This is compensation for services rendered, not a token, stake, or investment product.

Q. Why does this need Solana?

Solana gives Kraph three things a normal cloud does not: wallet identity, low-cost USDC settlement, and a programmable registry for node operators. That lets an agent pay for one infrastructure action at a time through x402, without creating a billing account or trusting a subscription platform to meter usage later.

Q. Where does the DePIN part show up?

The infrastructure is supplied by independent nodes, not one hosted database vendor. Kraph coordinates placement, payment, encrypted WAL replication, and attestation checks so those nodes can behave like a cloud network while still exposing the familiar Postgres/Supabase developer surface.

Q. Isn't a distributed database impossible with CAP?

Kraph isn't a distributed database. Each agent gets a single Postgres on one node — full ACID, single writer, same consistency as any self-hosted Postgres cluster. The decentralized part is placement, payment, and encrypted backups. There's no cross-node query, no consensus, no CAP tradeoff.

Q. What if a node dies?

Every WAL segment is encrypted (ChaCha20-Poly1305) and shipped to 2+ replicas in different regions. If the primary fails, the gateway reassigns to a replica, the agent provides the DEK, and Postgres replays from the encrypted backup. Operator agreements define reliability expectations and remedies.

Q. Is this actually fast?

Hosted Postgres platforms typically take 2–5 minutes to spin up a new project, and free tiers pause idle instances which adds another 1–3 minute wake-up. Kraph's cold start is ~15 seconds end-to-end and the paid tool call returns in 8 ms. Query latency is whatever Postgres + PostgREST give you on the host (11 k TPS / ~10 ms REST in our benchmarks).

Q. What do you mean by privacy-first hosting?

Kraph does not need the normal cloud billing identity layer. There is no credit-card form, no KYC flow, and no subscription account to create — access is tied to a Solana wallet, and paid tool calls settle through x402 USDC payments.

That means billing is pseudonymous rather than card-based. Solana transactions are public, so Kraph does not promise invisible payments; the point is that agents can rent infrastructure without handing over a personal billing profile, while workload data is protected separately by encrypted replication and mainnet-tier attestation.

Q. Can the node operator read my data?

On mainnet (SEV-SNP): no. The Postgres process runs inside an AMD enclave whose memory is encrypted at the hardware level. Every placement is verified against a fresh attestation report from /dev/sev-guest. On devnet the operator technically could, which is why devnet is for development only.

Q. How do secrets and env vars get handled?

kraph_set_env stores env vars scoped to edge functions — per-instance, encrypted at rest in the node's SQLite (ChaCha20-Poly1305 under the same per-instance DEK that encrypts WAL), TLS in transit. Rows on disk are always enc-v1:<base64(nonce‖ciphertext+tag)> — a sqlite3 .dump never yields plaintext.

On mainnet (SEV-SNP) nodes the plaintext only materializes inside the enclave when writing to the functions container .env file: hardware-encrypted memory means the operator cannot read it even with root. On devnet the operator running the node process can still read values from process memory during the brief decrypt-and-apply window — use mainnet if you need real confidentiality. Setting or unsetting restarts only the functions container (~1-2s, via docker compose up --force-recreate --no-deps functions). Postgres and every other service stay untouched. Listing via kraph_list_env returns keys and SHA-256 fingerprints by default; pass include_values=true to retrieve plaintext.