Matt Berryhill
Founder and operator
Accountable for Cynder’s product, protocol, payment safety, runtime controls, recovery model, and operating decisions.
Investor deck
Cynder makes paid software execution accountable.
Cynder
Agents can authorize, purchase, run, and reconcile bounded compute as one inspectable transaction.
Pre-seed thesisSeptember 2026Matt BerryhillContact through the existing introduction
The problem
An agent can prove it paid. It still cannot prove what happened next.
Hypothesis4 factsmust remain distinctAuthorization · payment · execution · verificationTarget design
Today, software pays a provider, invokes a service, and trusts the provider’s private record of the outcome.
Authorization ≠ Payment ≠ Execution ≠ Verification · When the result is missing or ambiguous, the agent cannot safely decide whether to retry, refund, dispute, or continue.
- Payment success is not execution success.
- A provider receipt is not universal proof of computation.
- Ambiguous external effects make blind retries unsafe.
Collapsing these facts creates duplicate effects, disputed payment, and unsafe recovery.
The solution
One signed intent becomes one accountable execution record.
Before
Pay an API. Call it. Trust its private success flag.
The changeSign the action. Settle the quote. Run the pinned workload. Inspect the outcome.
After
One record distinguishes authorized, paid, running, completed, failed, replayed, and unknown.
Cynder changes how software purchases and reconciles external execution.
Human role · Operators retain custody, security policy, and exceptional reconciliation.
Current state · Working single-node transaction engine; commercial reliability remains to be proven
Why now
Three mature rails have opened a new infrastructure layer.
Machine-native payment, stable settlement, and portable execution can finally compose in one software transaction.
- 01Machine-native payment
x402 turns an HTTP payment challenge into a signed authorization and settlement flow.
x402 ecosystem - 02Stable settlement
Native USDC on Base gives software a programmable stable-value payment rail.
Base and USDC infrastructure - 03Portable execution
OCI containers, Kubernetes, and Knative provide a mature substrate for bounded, elastic workloads.
Cloud-native ecosystem
Cynder can test paid demand before launching a chain, token, DAO, or compute marketplace.
The market
Cynder’s market is repeated paid execution—not the size of AI.
Not yet measuredPaying customersin the initial wedge
×Paid actions × priceannual execution value
=Serviceable revenueafter provider and delivery costs
Initial wedge
x402-native builders with funded Base wallets and recurring container workloads that fixed APIs cannot satisfy.
Method
Paying customers × executions per customer × average price × Cynder take rate.
Geography
Start with the reachable x402/Base developer wedge.
How it works
Every step leaves evidence the next step can trust.
- 1Create and sign
Bind signer, operation, workload, and idempotency key.
Customer or software agent - 2Quote and settle
Match exact USDC payment to the signed action.
Cynder payment boundary - 3Execute
Run the digest-pinned container within explicit limits.
Current Cynder operator - 4Record and reconcile
Record completion, failure, replay, or ambiguity for recovery.
Cynder state boundary
Human boundary · Custody and exceptional effects remain operator-controlled.
Owned advantage · Cynder preserves failure and ambiguity instead of turning every outcome into success.
Business model
Cynder charges per bounded action—and earns only what remains after delivery.
HypothesisBuyerDevelopers, agent platforms, and autonomous software operators
→Deploy · Invoke · Delete · lifecycle actionsPaid per successful bounded action
→ResultPurchased execution plus an inspectable outcome record
Customer payment − provider payout − compute − settlement − failure handling = contribution margin
- Gross collection is not protocol revenue.
- Unknown costs are not zero.
- Current prices are fixtures; paid workloads must establish margin.
Go-to-market
Win one repeated paid workload before building the network.
HypothesisFirst wedgex402-native builders running short-lived custom containers
Founder-led design partnerships around one reproducible paid workload
- 01
Find one workflow where ambiguity is costly.
- 02
Publish a reproducible workload recipe and exact price.
- 03
Run a bounded paid pilot beside the current alternative.
- 04
Measure repeat use, success rate, time to result, and margin.
Proof · Current state: wedge hypothesis; paid repeat behavior is the required proof.
Expansion · Add adjacent workloads first. Add independent supply only after repeat demand.
Competitive position
Clouds sell compute. Markets sell capacity. Cynder sells the accountable transaction.
Hypothesis- Managed serverless and agent sandboxesEasy execution inside one provider relationship.
Adopt the provider’s identity, billing, and private evidence model.
- Self-hosted Kubernetes or KnativeMaximum control over execution and policy.
Own payment, operations, recovery, and evidence.
- Decentralized compute marketplacesIndependent infrastructure supply.
Accept verification, liquidity, and governance assumptions.
- Ordinary paid APIs and x402 resourcesFast access to one known service.
Portability and execution evidence vary by provider.
CynderSigned, paid, bounded execution with explicit recovery evidence.
The evidence history can compound only after repeat buyers, operating history, conformance, and provider performance exist.
The team
One founder built the transaction boundary end to end.
Product direction · action protocol · payment safety · runtime controls · recovery model · economic discipline
Traction
The transaction engine works. Paid repeat use is the next proof.
8lifecycle actionsimplemented
18documented API routesworking product surface
1operator-controlled nodecurrent boundary
Nextpaid repeat usecommercial proof requiredNot yet measured
BUILT VS. NOT YET PROVEN · Repository and evidence review · September 2026
Product proof is not customer traction.
- Built: signed actions and durable idempotency
- Built: exact payment reconciliation and bounded execution
- Built: receipts, recovery, and explicit unknown states
- Next proof: paid repeat use with measured contribution margin
The raise
Fund the jump from working engine to repeat paid demand.
RaisingTerms in formationMilestone-based pre-seed
- 01
Prove the complete paid-action lifecycle in a production-like environment.
- 02
Win paid use for one bounded workload.
- 03
Convert that use into repeat paid behavior.
- 04
Establish per-action price, cost, and contribution margin.
The round will convert technical proof into one repeated, paid, margin-measured customer behavior.
- Product hardening
- Security and assurance
- Paid-pilot delivery
- Economic measurement
Review the working transaction engine and milestone financing thesis.
The vision
Own the transaction between payment and execution.
Cynder
Software should be able to discover, purchase, and inspect bounded computation across independent operators.
One accountable paid action first. The network only after demand.
Matt BerryhillContact through the existing introductionReview the working transaction engine and milestone financing thesis