Cynder Economic and System Whitepaper

The source establishes operation classes, not product-market fit. A caller can request a deployment, invoke a deployed service, or delete it through an authenticated and paid control path. The underlying product question remains: which user needs this boundary badly enough to pay a sustainable price, and why is the Cynder path better for that exact job than centralized serverless or self-hosted Knative?

The corpus contains no primary customer research, observed demand, willingness-to-pay study, or supported first-workload record. This paper therefore does not claim a market wedge. It uses an illustrative stateless HTTP image transformation only to make lifecycle and failure questions concrete. That example is hypothetical and should be replaced by a real trace when evidence exists.

At repository candidate f6039212ff23394b4ff6aa4bbbcc862874f16194, one cynderd process owns one Badger directory and coordinates the action lifecycle. DEPLOY, INVOKE and DELETE are independently priced. The service binds an authorized action to payment evidence, persists state, calls Kubernetes and Knative operations, and records receipts.

This is a source boundary, not a deployment boundary. The corpus does not show how many processes are running, where they run, which Base environment is configured, who controls the payment recipient, or whether any customer workload has reached a live service. The architecture is therefore described as implemented in pinned source—not observed in production.

A useful trust model starts with what each actor can do, not with what the role is called. The customer authorizes an action and payment. cynderd can admit or reject it, evaluate payment evidence, persist action state, dispatch a Kubernetes or Knative operation, and report a receipt. The x402 facilitator and Base participate in the payment leg. Provider infrastructure performs the workload. An operator-configured payTo receives settlement at the pinned source boundary.

Several authorities remain unknown: who controls pricing, the settlement recipient, refunds, pause behavior, upgrades, software release, recovery, and custody. Proposed Safe, treasury, settlement-contract, and governance roles are design material. They must not be projected backward into the current source.

The source flow begins with an action intent: method, route, operation type, idempotency key and immutable action digest are bound by EIP-191 authorization. cynderd issues or evaluates the x402 payment requirement, accepts evidence for the bounded action, persists the payment binding and action state, and only then dispatches DEPLOY, INVOKE or DELETE to the off-chain execution plane.

The payment state and execution state must remain separate. Payment may be unseen, observed, accepted, rejected or later require reconciliation. Execution may be pending, running, succeeded, failed or unknown. A paper that collapses both into paid/successful hides who bears the cost of partial work, retries, refunds and external side effects.

Kubernetes and Knative provide an execution substrate, not an automatic adversarial proof system. A payment receipt can show a payment transition. An action digest can commit to bytes. A log can record an event under collection assumptions. A signature can attribute a statement to a key. None of those facts alone establishes that the workload ran correctly, produced the intended result, protected secrets, used honest metering or remained available.

The current source provides a useful action and evidence seam, but several service properties remain undefined: runtime isolation, image provenance, secret visibility, egress, trusted metering, dispute and appeal, output verification, retention and side-effect safety. Those unknowns should constrain supported workloads rather than disappear behind generic language.

At the pinned source revision, x402 v2 exact USDC behavior on Base precedes DEPLOY, INVOKE and DELETE. Settlement targets an operator-configured payTo. This provides a payment gate and evidence-binding path; it does not by itself allocate provider reimbursement, network revenue, refunds, reserves or future liquidity.

A future four-way accounting split may separate deployer credit, provider credit, network revenue and liquidity reserve. That is DESIGN, not current implementation. Any future ledger must use deterministic integer base units, document remainder handling, protect accrued provider liabilities and reconcile quote, transfer, ledger and payout totals without unexplained variance.

The source includes prices but not a measured cost ledger. Deploy is priced at $0.10, invoke at $0.001 and delete at $0.01 in the pinned fixture. Those values do not establish what a provider spends, what Cynder spends, what failures cost, or whether the resulting contribution margin is positive.

A credible service model must separate deploy, invoke and delete; warm and cold execution; CPU, memory, egress and supported accelerators; successful, retried, timed-out, disputed and refunded operations; and the timing of provider payout. Unknown inputs remain unknown. Assigning zero to egress, support, verification, refunds or payment costs would manufacture viability.

Customers can pay for the evidenced service in USDC. That makes USDC the baseline counterfactual for every proposed CYNDER role. The paper must ask what service property fails without CYNDER, who must acquire or hold it, how long the obligation lasts, who receives it, which realized service margin funds any acquisition or discount, and what rational recipients do when they need stable operating cash.

No CYNDER token, supply schedule, provider reward, liquidity position, staking contract or governance system is evidenced in the audited repository. Candidate values in the model—such as a 10% network-fee-only discount or 25% of realized network revenue to protocol-owned liquidity—are test parameters, not adopted policy.

The frozen release is cynder-tokenomics-conservation-v2 at source revision 88e588d507ca4a080499649d3b3471f2accf3a49. It uses schema 2.0.0, Python 3.12.3, seed 20260831 and a 156-week horizon. The bundle records 568 pairwise coverage cases, 500 baseline Monte Carlo paths and 17 stress rows.

Its adoption, operating cost, payment mix, provider selling and liquidity inputs are assumptions. The output is not a forecast and does not estimate the probability of Cynder's business succeeding or failing. Its value is comparative: under the same model structure, the candidate token policy does not materially outperform the USDC-only case and neither establishes sustainable service economics.

The pinned single-daemon boundary concentrates admission, payment evaluation, action state, execution dispatch and receipt production. Payment targets an operator-configured recipient. Receipts are digest-bound but not node-signed. Badger is local to the daemon boundary. These facts make operational evidence possible, but they do not remove operator, storage, custody or software-release trust.

Future mechanisms add their own failure surfaces. Shared settlement introduces signer, upgrade and contract risk. CYNDER introduces conversion, custody, liquidity and policy risk. Staking adds fault-definition and appeal risk. Governance adds capture and emergency-authority risk. None should be activated merely to make the architecture appear more complete.

At the audited source boundary, Cynder is a single-daemon, Badger-backed service for paid off-chain Kubernetes and Knative actions. x402 exact USDC behavior on Base gates execution. The design creates an auditable seam between authorization, payment evidence, persistent action state and provider execution, while leaving correctness, decentralization, custody, service economics and deployment truth unresolved.

The frozen model's negative result is not an embarrassment to hide. Under its assumptions, neither the USDC-only nor candidate-token case establishes sustainable economics, and adding the candidate token policy does not repair the modeled deficit. That conclusion directs the next iteration toward measurement rather than promotion.

CYNDER remains deferred until a precise role demonstrates a necessary service benefit over the same-input USDC design, survives provider selling and severe price/liquidity stress, and is funded from realized margin after liabilities and reserve needs. If that evidence does not emerge, the honest outcome is to retain a USDC service and reject the token role.