Looking Forward
Cordova is a decentralised system for those who value privacy, freedom from subscriptions, and independence from Big Tech. Independent developers and researchers currently find themselves in a difficult position: they must pay subscription fees while handing over proprietary data, or attempt to run resource-intensive models on underpowered hardware. At the same time, thousands of GPUs around the world are gathering dust, as profits from mining are at an all-time low. Cordova aims to bring these two sides together, allowing some to sell computing power whilst others can run any AI model independently and with confidence. As we launch our MVP, we are developing the platform towards a fully federated system where any user can act as a server and end-to-end encryption guarantees data privacy
Preliminary score
- Value for the user11.0 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI8.0 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing10.0 / 20
Tests, examples of failures, and comparison with the current approach.
- Feasibility6.5 / 15
Data requirements, running costs and a clear next step.
- Originality3.0 / 10
A meaningful difference from common solutions.
What the judges wrote
- Claude Opus 5.5Preliminary34/100
- Strengths
- Your engineering scaffolding is real and carefully bounded: an HTTPS edge, Go gateway, private WSS mock node, SSE streaming, accounts, API keys and a usage dashboard are reported running, with Redis/Kafka kept on private networks. Your status report is unusually honest. You state exactly what passed (20/20 unit tests, 15 validated REST routes, smoke tests), what was skipped, and what remains unverified, including real inference, multi-node routing and cost versus alternatives. Marking mock responses with an X-Cordova-Mode header and a [MOCK] prefix is a good practice that avoids overclaiming.
- To improve
- The prototype contains no AI yet: every generation is synthetic, so the core scenario of running a model on someone else's GPU has not been demonstrated even once. Connecting a single llama.cpp node end to end should be the top priority. Your user and problem stay generic ('researchers', 'extortionate fees'), and the project does not fit the enterprise track's ask to automate one company workflow with an adoption metric. Name a concrete customer and the job they would offload. Also benchmark your price per token and latency against Vast.ai, Akash, Petals or a hosted API, since decentralised GPU marketplaces already exist and you need to show what makes yours different.
- GPT-6 AstraPreliminary43/100
- Strengths
- Your submission clearly distinguishes the implemented API, account and streaming infrastructure from synthetic generation and planned federation. Your reported unit tests, contract fixtures and smoke checks provide useful engineering evidence, while skipped suites and concurrency limits are documented honestly. Your local deployment instructions and specific llama.cpp integration plan establish a concrete next step.
- To improve
- Your next milestone should demonstrate a real model job from client through gateway to an inference node, with reproducible outputs and measured resource requirements. Run the skipped integration suites and benchmark cost, latency and failure recovery against local execution and a hosted alternative. Define how data remains private from third-party node operators during computation; transport encryption alone does not substantiate the deck’s absolute-privacy claim. Choose one initial customer workflow, quantify its adoption benefit and explain your advantage over existing GPU marketplaces.
The team
Abbas Lütvəliyev
developer
Ülvi Zeynallı
developer
Revan AxundzadeLead
product