darwin

$darwinSolana

Checkedin 5m 56s · Oct 6, 06:25 UTC

Darwin is a Solana utility token presented as a way to buy credit for an AI model-routing API and rented-GPU service (review; C1–C5). The mint has no mint or freeze authority, its metadata is immutable, and the website references the supplied address (facts; metadata; site/mint-referenced). Wallet sign-in and workspace creation were observed, but tests of routing, API compatibility, GPU specifications, burn-to-credit conversion and upgrades were inconclusive because the tester lacked tokens, credit or authenticated access. Privacy and key-storage assurances remain unverified, and the source of cash to fund compute purchased with burn-created credit is not explained (C6–C7; skeptic).

darwincompute.com/docsproductC1

Darwin grades each request by rules, not with another model: words like plan, migrate or refactor push it up, words like rename, summarise or format push it down, and attached tools add a little.

Darwin says it grades requests and routes them across a model ladder, moving easier requests to cheaper models as the top model's budget declines, while keeping a conversation on one model unless it fails or runs out.

UntestedNot tested this run. Checked against Wallet test

Testing was inconclusive: no request could be sent without workspace credit, so difficulty grading, budget transitions and conversation stickiness were not observed.

To settle it: Configure a ladder and budget in the app, send requests with varied wording and tools, and inspect the x-darwin-model and x-darwin-rung response headers.

Wallet test, inconclusive: The app and docs describe the claimed grading, budget-based routing, and keeping a conversation on one model unless it fails or runs out. Those descriptions are not runtime verification; no request was routed during this test.

Skeptic: plausible

Rule-based request grading, budget thresholds and model fallback are feasible routing behaviors, and the docs describe how they are intended to work. The page does not independently establish routing quality or cost savings.

darwincompute.com/docsproductC2

POST /v1/chat/completions OpenAI chat completions, streaming or not, with tools.

Darwin says its API and MCP server support OpenAI and Anthropic request formats, and documents endpoints for chat completions, messages, token counting and models.

UntestedNot tested this run. Checked against Wallet test

Unauthenticated endpoint requests returned 401; successful authenticated format compatibility and MCP behavior were not tested. These responses do not refute compatibility.

To settle it: Use a Darwin key to call the documented endpoints with OpenAI- or Anthropic-compatible clients and inspect their responses.

Wallet test, inconclusive: The documentation lists the endpoints and claims OpenAI/Anthropic compatibility, but I did not verify successful authenticated responses. The 401 responses were unauthenticated browser requests, not evidence that the supported formats fail.

Skeptic: plausible

The documented OpenAI- and Anthropic-format endpoints and MCP interface are technically feasible. The documentation is a useful specification, though independent implementation testing is not provided here.

darwincompute.com/docsproductC3

Model Qwen3 30B A3B Instruct, FP8 Context 65,536 tokens; replies are capped at 8,192 Formats OpenAI and Anthropic, streaming, tool calls Price $0.10 in and $0.40 out per million tokens, paid from credit

Darwin says its fallback GPU model is Qwen3 30B A3B Instruct FP8, with 65,536-token context, replies capped at 8,192 tokens and a price of $0.10 per million input tokens and $0.40 per million output tokens.

UntestedNot tested this run. Checked against Wallet test

No GPU response or credit deduction was observed; the documented model, limits and prices remain untested.

To settle it: Send requests routed to Darwin's GPU and check the reported model, output limits, usage and workspace credit changes.

Wallet test, inconclusive: The published specification matches the claim, but model identity, output cap, usage accounting, and credit deduction were not verified by an actual GPU response.

Skeptic: plausible

Running a Qwen model on rented GPUs and charging usage by token is feasible. The stated model deployment, limits and prices are project claims; the pages do not independently verify that the service is operating at those specifications.

darwincompute.com/docstokenomicsC4

Each million burned adds $5 of credit. The Credits page builds the burn for you: one transaction from your wallet that burns the tokens and carries the memo darwin:<workspace id>.

Darwin says it credits workspaces at $5 per million $DARWIN tokens burned, with burns linked to a workspace through a memo.

UntestedNot tested this run. Checked against Wallet test

The tester held no DARWIN and performed no burn. Mint identification does not establish memo processing or the claimed credit conversion.

To settle it: Review the Solana burn transaction and memo, then compare the resulting workspace credit balance.

Wallet test, inconclusive: The UI describes a normal Solana burn transaction with a workspace memo and $5 credit per million tokens, but no burn or corresponding credit was produced. The mint lookup confirmed the provided address is the DARWIN mint; it does not verify the crediting flow. No token burn was performed.

Skeptic: plausible

A Solana burn transaction with a workspace memo can be read and credited once by an application. The $5-per-million rate is an internal credit rule, not evidence that the operator receives $5 in cash for each million tokens burned.

darwincompute.com/docstokenomicsC5

Pro Darwin's GPU requests go to gpt-oss-120b instead of Qwen3 30B, with a 128K context, replies up to 32K tokens and 16 requests at once. Tokens cost $0.25 in and $1 out per million. $3 a day Warm GPU Keeps a worker running on Darwin's GPU so requests never wait for a cold start. $2 an hour Warm Pro GPU The same for the Pro GPU. Needs Pro. $4 an hour

Darwin says credit can purchase Pro, Warm GPU and Warm Pro GPU upgrades, with listed rates of $3/day, $2/hour and $4/hour respectively.

UntestedNot tested this run. Checked against Wallet test

The rates appeared in the UI, but upgrade activation and credit deduction were not verified; the workspace had zero credit and the attempted interaction was inconclusive.

To settle it: Purchase an upgrade in the app and verify its activation, behavior and credit deduction.

Wallet test, inconclusive: The listed rates match the claim, but an upgrade was not verified as purchased or activated. With no workspace credit, the operational behavior and deduction could not be tested.

Skeptic: plausible

Charging credit for model tiers and warm compute is a workable pricing design. Whether the listed rates cover actual GPU and operating costs is not established, and credit creation via burns does not itself fund those costs.

darwincompute.com/docssecurityC6

Darwin keeps the model, token counts, cost, timing and status of each request, and never the prompt or the reply. Provider keys are encrypted at rest.

Darwin says it stores request metadata but not prompts or replies, encrypts provider keys at rest, and does not store prompts sent to its rented GPU workers.

UnverifiableCan't be checked. Read against Site capture, Claim review

Backend retention, encryption at rest and rented-worker logging policies cannot be established from the supplied public pages or client interactions; no independent backend inspection is provided.

Skeptic: doubtful

Avoiding prompt/reply logging and encrypting provider keys are technically achievable, but these are broad operational privacy and security assurances. The reviewed documentation provides no independent audit or verification.

darwincompute.com/docssecurityC7

Darwin checks each key with its provider before saving it, encrypted, and only uses it to call that provider for your requests.

Darwin says provider keys are checked with the provider before saving and are stored encrypted for use only when calling that provider for a user's requests.

UnverifiableCan't be checked. Read against Wallet test, Site capture

Provider-key validation could be tested separately, but no such test occurred; the broader encrypted-storage and exclusive-use assurances require access to internal controls not available in this dossier.

Skeptic: plausible

Testing a provider key before storage and encrypting it for later use are feasible practices. The documentation does not independently verify the implementation or key-handling controls.