QOR

Verified compute and storage contracts for a peer-powered cloud market.

QOR is a marketplace control plane where buyers fund compute or storage jobs, providers accept visible contracts, and payouts are released only after proof is available.

Inspiration

Most cloud products make infrastructure feel clean for buyers, but the trust model underneath is still centralized. Developers pay one platform, providers have no way to participate directly, and proof of work is usually hidden inside internal dashboards.

We wanted to explore what a more open cloud market could feel like if the buyer and provider experience were designed together: clear pricing before the job starts, escrow-style settlement while work is pending, and receipts that make compute and storage work inspectable.

Market Context

Cloud infrastructure is a large and still-growing market. Synergy Research Group reported that cloud infrastructure services reached about $330.4 billion in 2024, up roughly $60 billion from 2023, with generative AI responsible for about half of cloud infrastructure market growth over the prior two years.

Gartner also projected worldwide public cloud end-user spending at $675.4 billion in 2024, driven by generative AI and application modernization. That matters for QOR because AI workloads increase demand for compute, storage, and bandwidth while also making cost, capacity, and provider trust harder for smaller teams to manage.

Business Model Projection

QOR can take a marketplace fee on completed resource contracts. The example projection uses a 10% platform take rate for matching, escrow coordination, verification, dispute handling, and payout orchestration.

At a year-one exit run rate of $1.25 million in monthly resource volume, a 10% take rate produces about $125,000 per month in platform revenue. The projected curve ramps from early monthly revenue in month one to a $125K/month exit run rate by month twelve as marketplace volume, provider supply, and buyer repeat usage improve.

This is an illustrative model for the opportunity, not current revenue.

What It Does

QOR lets a buyer log in, fund a compute or storage contract, choose a preferred provider or leave the job open to eligible nodes, and track the job from escrow to release.

For compute jobs, providers run a deterministic command and return a receipt with exit code, stdout, duration, and an output hash.

For storage jobs, buyers can paste text or upload a file. QOR stages the artifact, sends it to a provider, records a storage receipt, and lets the buyer issue a salted challenge. The provider must answer with the expected SHA-256 proof before the storage payout can be released.

Providers get their own workspace with an eligible contract queue, resource utilization, wallet balance, queued revenue, reliability, and an earnings feed.

The demo path shows the full loop: reset marketplace, fund compute, fund storage, provider accepts work, compute receipt is generated, storage artifact is pinned, a storage challenge passes, and both payouts are released.

How We Built It

React 19 frontend with React Router for login, buyer workspace, provider workspace, and code maps.
Express 5 backend with cookie-backed sessions and role-gated buyer/provider routes.
JSON-backed local persistence in .qor_app_data/state.json for the hackathon prototype.
Local artifact staging in .qor_app_data/artifacts/ for storage payloads and uploaded files.
Node child_process.exec for demo compute execution with stdout, stderr, timing, and output hash receipts.
SHA-256 artifact hashes and salted storage challenges for a transparent storage verification path.
Escrow-style accounting in application state: buyer balances decrease on contract creation, funds stay pending while work is active, and provider balances increase only after release.
A guided demo terminal that drives the same app state through a judge-friendly sequence.

Challenges We Ran Into

The hardest part was keeping the prototype honest. It would have been easy to call every receipt a cryptographic proof or pretend that a local coordinator is already a decentralized network. Instead, QOR labels what it can prove today: deterministic compute output, artifact hashes, challenge responses, balances, and job state transitions.

The second challenge was designing both sides of the market. A cloud marketplace only makes sense if buyers understand the risk before funding work and providers can see why a contract is worth accepting. That pushed us to build separate buyer and provider workspaces instead of a single admin dashboard.

We also rewrote the app from an older static/Python prototype into a React and Node implementation, while keeping the older files around as reference. The active product is now the Node/Express app described in the README.

Accomplishments

Built a real login flow with starter buyer and provider accounts.
Created separate buyer and provider workspaces instead of a one-sided demo.
Implemented funded compute and storage contracts with escrow-style balances.
Added storage file upload and pasted payload support.
Added compute receipts with stdout and output hashes.
Added storage receipts, salted challenges, challenge responses, and gated payout release.
Added provider resource utilization, reliability, wallet, queue, and earnings views.
Added a one-click guided demo that produces two released jobs, zero remaining escrow, and visible proof artifacts.
Added /diagrams code maps to explain runtime stack, API flow, job lifecycle, and persistence.

What We Learned

The useful product boundary is not "decentralized cloud" in the abstract. It is the contract loop: intent, escrow, match, execute, prove, verify, settle. Once that loop is visible, judges and users can reason about which parts are production-ready and which parts need stronger cryptography or decentralization later.

We also learned that proof UX matters as much as proof mechanics. A buyer should not need to read backend logs to know whether work is ready. QOR puts hashes, challenge status, escrow, release buttons, and ledger events in the product surface.

What's Next

Replace local escrow-style accounting with a smart contract or payment rail.
Move storage verification from full-file salted checks to chunked Merkle challenges.
Add signed provider receipts and stronger identity for providers.
Add redundant compute execution or reproducible sandboxing for higher confidence.
Replace JSON persistence with a production database.
Add provider registration controls for capacity, region, price, and stake.
Add marketplace ranking based on reliability, price, available capacity, and buyer constraints.