KenMatch

KenMatch is a public board for proposing, ranking, funding, launching, and auditing long-running AI work. Each unit of work is called a Ken. A Ken can be an open tool, a civic workflow, a scientific evidence map, a repair assistant, or a creative service that benefits from sustained compute, checkpoints, public feedback, and visible funding.

Platform Simulator

Mission and Background

KenMatch is built around a simple idea: everyone should have a public, legible opportunity to decide which long-horizon AI projects receive time, review, and funding, without relying on wealth as the allocator. (1)(2)(12)(5)(3)(4)

As frontier models evolve from short, single-turn assistants into long-context, tool-using agents, the “few queries” standard is rapidly becoming obsolete. The opportunity to participate in the alignment of long-horizon AI effort toward public challenges, services, research, and creative endeavors, however, is likely to remain capital and access constrained. KenMatch interrupts this trend. Major AI providers now document advanced reasoning, long context, and agentic capabilities as first-class features, underscoring a growing demand for solutions democratizing access, participation, and governance, independent of capital. (1)(2)(3)(4)

Concept

Kens

A Ken is a proposed unit of long-running AI work. The public board shows its goal, evidence, risks, requested lane, funding path, current review state, launch timing, and audit trail.

Public Participation

KenMatch separates fast public signal from scarce allocation voice:

• Public vote: simple upvote or downvote support.
• Voice allocation: quadratic credits assigned by signed-in contributors.
• Comments: threaded, voted, timestamped discussion with visible stake.
• Attestation policy: new or partially reviewed accounts can participate with review-aware limits until stronger verification lands.

Launch and Review

Kens can stay public before launch. Launch requires visible release conditions:

• safety status
• checkpoint gates
• reproducibility notes
• rollback plan
• run updates and evidence logs

Funding

KenMatch keeps funding legible without turning rank into a purchasable advantage:

• sponsor pools tied to specific Kens
• reusable service revenue routed into the treasury
• committed and projected support shown separately
• founder and operations split reported separately from public compute support

Coordination

KenMatch centralizes the proposal, refinement, and prioritization of “long-horizon tasks,” including, but not limited to:

1. deep scientific and technical research that benefits from iterative investigation and synthesis,

2. complex software development and maintenance,

3. public-interest analysis and tooling,

4. and other high-leverage work whose results can be validated, reused, and compounded.

The platform is designed for tasks that are naturally multi-stage: they require planning, intermediate checkpoints, continuous evaluation, and the ability to pause and resume without losing state.

Proof-of-value Allocation Credits

KenMatch’s allocation credits are not a pay-to-win instrument. In KenMatch’s intended design, allocation rights are earned through contribution and curation.

Users earn “proof-of-value” credits by doing work the community can audit and validate, such as:

1. proposing tasks that generate high-quality, verifiable outputs,

2. improving existing tasks (clarifying requirements, adding constraints, testing plans),

3. accurately curating (supporting proposals that later prove to be genuinely valuable),

4. and contributing measurable infrastructure support (e.g., verified computation or evaluation labor) under clear rules.

The governance literature on token platforms emphasizes that token issuance can align incentives under some conditions, but token voting also introduces capture risks and demands careful mechanism design. KenMatch therefore treats tokens as allocation credentials, not a speculative asset class. (13)(14)

Safeguarded Democratic Ranking

KenMatch’s “value” cannot be a single number. It must be the result of a process that is:

1. inclusive (broad participation),

2. sybil-resistant (identity and duplication attacks are managed),

3. auditable (why a task won is legible),

4. and safe (high-severity dual-use is screened).

A defensible default for expressing intensity of preference is quadratic voting, where the cost of concentrating votes rises quadratically. This voting rule is motivated in the mechanism design literature and is widely discussed as a way to incorporate preference intensity rather than only headcount, while still requiring serious attention to secure implementation and fraud resistance. (15)(16)

KenMatch pairs broad voting with a constrained “safety and validity” layer that can block tasks that plausibly create severe harm or cannot be evaluated responsibly. This is aligned with mainstream AI risk management guidance (governance, measurement, monitoring, and mitigation), instead of a blind trust approach. (24)(25)(26)(27)

Allocation Protocol

KenMatch organizes long-horizon computational tasks into explicit duration tiers, because the duration of frontier LLM’s sustained computational effort is a finite resource, while the management of energy use and facilities pose additional constraints.

KenMatch’s baseline tiering is:

1. Months: top 3 projects per category

2. Weeks: top 10 projects per category

3. Days: top 100 projects per category

Modern accelerator systems are power-dense (e.g., DGX-class systems are in the tens of kilowatts), and at national and global scale data center electricity demand is now a material planning variable. Long-horizon allocations must therefore be explicit about duration, checkpointing, and rollback, as well as about evaluation and stopping conditions. (6)(7)(10)

Execution Layer Neutrality

KenMatch is execution-layer neutral by design: it can route long-horizon computation to (1) enterprise APIs, (2) dedicated clusters, and/or (3) decentralized computation networks with verifiable work.

Decentralized computation is an active design space with concrete architectures:

1. decentralized marketplaces for leasing computation capacity and managing deployments, bids, and leases, (20)(21)(23)(22)

2. protocols for running ML computation across heterogeneous devices with trustless verification, (22)

3. and peer-to-peer “intelligence markets” that reward contributors based on ledgered value signals. (23)

KenMatch contends that the collective deserves a legitimate mechanism to determine which ideas and problems will benefit from the long-horizon effort of advanced API-accessible models, without defaulting to wealth as the allocator.

Stewardship, Legitimacy, and Public Benefit

KenMatch treats legitimacy as a product requirement.

A credible democratic computation platform must:

1. publish clear rules for what can and cannot be run,

2. maintain transparent logs of decisions and allocations,

3. implement rigorous evaluation and rollback practices for long-horizon agents,

4. and align incentives so that the platform produces durable public value (e.g., tools, research artifacts, verified analyses) rather than attention-grabbing but unverifiable outputs.

This stance reflects widely adopted principles for AI alignment, including risk management, accountability, transparency, and respect for human rights and democratic values. (24)(25)(26)(27)

Vision

KenMatch seeks to equalize the long-horizon deployment of frontier AI toward the realization of collective value. This necessitates broad participation to identify the most brilliant and innovative ideas across humanity’s collective creativity, taste, and imagination. As equal stakeholders in a society increasingly permeated by unprecedented computational intelligence, we have a right to curate the most promising ideas of collective value for frontier autonomous AI deployment. Capital constraints should never computationally constrain our best ideas.

Our creativity, taste and imagination trained frontier LLMs’ capability as knowledge creation and complex development engines; it is our right to govern their alignment in service of our flourishing. KenMatch enables democratic, transparent, and merit-sensitive joint operation of long-horizon frontier computation, allocating access proportional to demonstrated contribution and value rather than capital.

Features

• Public proposal feed with search, categories, stage/tier filters, and realistic community-facing examples.
• Demonstration contributor accounts and server-side sessions.
• Earned quadratic voice for scarce allocation, with separate up/down pulse voting for broad public curation.
• Threaded comments with replies, voting, and small stakes for discussion quality.
• Proposal quality bonds, checkpoint approval gates, run metadata, rollback plans, and visible blocked work.
• Economics surface for supported service packaging, screened evaluation licensing, compute routing, private execution lanes, sponsorship routing, treasury entries, and the 80/20 public reporting split.
• Treasury coverage governor that automatically signals a higher treasury share when reserve coverage dips below the target threshold.
• Structured sponsor commitments with projected, simulated, and committed funding states plus optional Stripe Checkout for live sponsor intake.
• Sandbox-backed demo Kens with simulated capital, model lineups, API spend, pilot-user counts, and sample outcomes shown directly in the UI.
• Three theme modes (Light, Dark, and OLED), rich motion, strong visual hierarchy, and updated KenMatch icon/favicons.
• Public board at /kens with search, category, lane, status, and sort filters.
• Real account creation and persistent signed-in accounts with full account management (edit profile, change password, licensing consent).
• System roles (contributor, moderator, admin) and email verification readiness on account records.
• Public contributor profile pages at /profiles/[id] showing activity history, proposed Kens, and voice allocations.
• Generated SVG avatar identicons based on contributor name and hue.
• Universal sitewide search (Ctrl+K / Cmd+K command palette) across Kens, profiles, governance events, and categories.
• Bookmark and share buttons on Ken detail pages for engagement and sharing.
• Responsive mobile navigation drawer with animated hamburger toggle.
• libSQL-backed persistence with local-file or remote libSQL support.
• Public upvote/downvote signal, separate quadratic voice allocation, and threaded comments with voting.
• Ken timing metadata: created and updated timestamps, launch countdown, submission age, compute usage, remaining runtime window, and completion state.
• Incremental run audit history for partial delivery, early completion, and checkpoint-by-checkpoint evidence notes.
• Economics and treasury views with committed versus projected support, sponsor pools, restricted funding, simulated runway, safety reserve coverage, and sponsor covenant details.
• Governance view with blocked Kens, attestation state, enforceable participation limits, review timing, and visible decision logs.
• Security headers (CSP, HSTS, CORP, COOP, X-Frame-Options, Permissions-Policy), host filtering, request-origin checks, structured rate limits, security event logging, optional Turnstile verification, and public-safe health checks with deployment version reporting.
• Standalone Next.js Docker build with OCI labels and container healthcheck, non-root container runtime, read-only filesystem with tmpfs, loopback-only Synology deployment, and public-hosting guidance for Cloudflare Tunnel or equivalent origin shielding.

Stack

• Next.js 16
• React 19.2
• Tailwind CSS v4
• libSQL TypeScript client for local-file or remote libSQL persistence
• zod for form and environment validation

Local Development

npm install
npm run dev

Open http://localhost:3000.

Environment

Copy .env.example and set values as needed.

• DATABASE_URL: leave empty for the local file database, or point it at remote libSQL.
• DATABASE_AUTH_TOKEN: auth token for remote libSQL.
• KENMATCH_DB_FILE: local fallback database path.
• KENMATCH_SESSION_COOKIE: cookie name for the signed-in account cookie.
• KENMATCH_SESSION_DAYS: sign-in lifetime in days.
• KENMATCH_ALLOW_SIGNUPS: set to false to disable public account creation.
• KENMATCH_PUBLIC_ORIGIN: exact public HTTPS origin for redirects, Stripe success URLs, and host validation.
• KENMATCH_ALLOWED_HOSTS: comma-separated list of allowed public hostnames.
• KENMATCH_HEALTH_TOKEN: token for detailed health responses.
• KENMATCH_TREASURY_TARGET_MONTHS: reserve target used by the economics view.
• NEXT_PUBLIC_TURNSTILE_SITE_KEY / KENMATCH_TURNSTILE_SECRET_KEY: optional Cloudflare Turnstile keys for public forms.
• STRIPE_SECRET_KEY / STRIPE_WEBHOOK_SECRET: optional Stripe Checkout and webhook settings for live sponsorships.
• DEPLOYMENT_VERSION: optional deployment identifier exposed in the health endpoint and passed into Next.js.

Scripts

npm run dev
npm run typecheck
npm run lint
npm run test
npm run build

Deployment

KenMatch ships with a standalone Next.js build configuration and a Docker image intended for self-hosting.

• next.config.ts sets output: "standalone".
• npm run build uses next build --experimental-build-mode compile --webpack, which produces the standalone server artifact used by the Docker and Synology deployment flow in this repository.
• Dockerfile runs the generated standalone server as a non-root user.
• docker-compose.synology.yml mounts persistent local data, keeps the container read-only except for /app/data, and binds the app to 127.0.0.1:3000.
• docker-compose.synology.tunnel.yml adds a cloudflared sidecar for a direct Cloudflare Tunnel deployment from Synology.
• The /api/health health endpoint exposes a public-safe summary and can return detailed diagnostics when KENMATCH_HEALTH_TOKEN is supplied.
• For local development, KenMatch constructs a file-backed SQLite-compatible database via libSQL.
• For public deployment, DATABASE_URL and DATABASE_AUTH_TOKEN can be specified for managed remote libSQL database integration.
• Security headers, host filtering, and mutation-origin checks live in middleware.ts.
• For public Synology NAS deployment, read docs/synology-nas-deploy.md and docs/public-security-hardening.md before exposing the service.

Main Routes

• / overview and featured Kens
• /kens public Ken board
• /kens/[slug] Ken detail, timing, voting, audit, and comments
• /submit Ken submission
• /governance governance, attestation, and blocked Kens
• /economics treasury and revenue logic
• /auth sign-in and account creation
• /account account settings, profile editing, password changes, and licensing consent
• /profiles/[id] public contributor profiles with activity history

Legacy /tasks routes now redirect to /kens routes.

Repo Map

• src/app routes, layout, health endpoint, and server actions
• src/components public UI, timing display, voting, comments, sponsor intake, auth, and shell
• src/lib/attestation.ts participation policy derived from attestation state
• src/lib/db.ts database schema, seeding, hydration, account persistence, funding ledger, rate limits, and write flows
• src/lib/economics.ts revenue stream summaries, treasury coverage, and governor split logic
• src/lib/security.ts form hardening, origin checks, rate-limit integration, and Turnstile verification
• src/lib/stripe.ts optional hosted sponsor checkout wiring
• src/lib/seed.ts and src/lib/seed-plus.ts realistic demo data
• docs/architecture.md implementation structure
• docs/requirements-traceability.md conception-to-code mapping
• docs/synology-nas-deploy.md Synology NAS deployment guide
• docs/public-security-hardening.md public-hosting security checklist
• cloudflared/config.yml.example Cloudflare Tunnel example configuration for NAS deployments

Notes

• The default local deployment uses a file-backed libSQL database. For public internet deployment, use a managed remote libSQL instance when possible.
• The included Synology compose file is intentionally loopback-only. Put Cloudflare Tunnel or another reverse proxy in front of it instead of exposing the container directly.
• The deployment artifact in this repository is currently produced through Next.js compile mode. The generated standalone server was validated locally in this session, but the underlying build mode is still marked experimental by Next.js.

Learn More

1. KenMatch_Conception.md

2. KenMatch_DeepWiki.md

References

1. Data center energy demand and projections: U.S. Department of Energy summary of LBNL report (U.S. share, 176 TWh, 2028 projections). (6)(7)(8)
2. Global data center electricity demand: International Energy Agency Energy and AI report pages (415 TWh in 2024; 945 TWh by 2030; sensitivity cases). (7)(8)
3. Hardware power density: NVIDIA specs for H100 TDP and DGX B200 system power usage. (9)(10)
4. Frontier model capabilities and access gating: OpenAI GPT-5.4 release + model docs; Google DeepMind Gemini 3.1 Pro model card; Anthropic Opus 4.6 release + model overview; xAI API models. (1)(2)(12)(5)(3)(4)
5. Governance mechanisms: Quadratic voting paper summary; secure QV implementation concerns. (15)(16)
6. Token governance and DAO voting risks: Philadelphia Fed token governance research; DAO voting mechanism centralization risks. (13)(14)
7. Risk and stewardship frameworks: NIST AI RMF and GenAI profile; OECD AI principles; DeepMind Frontier Safety Framework. (24)(25)(26)(27)
8. Decentralized compute / verification primitives: Akash deployment marketplace docs; Gensyn protocol overview; Bittensor whitepaper. (20)(21)(23)(22)