mcpField
K
knos

knos

Remote
github.com/drexthealphaFinance1Updated today
Repository

About knos

knos provides a proof-based payment process for research and software work. It checks demand with Qloo, holds test funds on Solana devnet, and releases them against GitHub checks or referee outcomes; it currently has no customers and uses test funds only.

Key features

  1. 01Check market demand with Qloo
  2. 02Set targets and deadlines in briefs
  3. 03Hold test funds on Solana devnet
  4. 04Pay against GitHub checks or referee outcomes
  5. 05Rebuild work counts independently

Use cases

  1. 01Assess demand and launch locations for product ideas
  2. 02Set acceptance terms for research or development milestones
  3. 03Pay for tasks after a PR passes checks and is merged

MCP support

knos provides a remote HTTP MCP endpoint for agents to connect to its work and payment flows. The README documents a Claude Code command and Bearer-key configuration.

Configuration

Remote servers need no local install. Pick your client, then copy the config or install in one click.

Endpointhttps://knos.onrender.com/mcp
Copy install command
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

Run commands in a terminal; paste JSON into the client’s MCP config and restart. Servers that need sign-in will prompt on first connect.

Packages
pypiknos0.4.0

Tools

18
ParameterTypeRequiredDescription
repostringNoonly this repository, as owner/name
limitintegerNohow many to return

Details

From the project README

Knos

Knos carries research across the valley of death: see who wants it and where, then get paid only on proof.

A demand check on Qloo sets the terms, and the money waits on Solana until the proof passes.

Ready briefs: 2.08x fewer output tokens, 70% vs 5% passed (measured).

Devnet, test money, no customers yet.

Check demand · Check every claim yourself

How it works

flowchart TB
    idea["A paper or an idea"] --> demand["Demand check on Qloo: who wants it, the launch city and the pre-order target"]
    demand --> ready["Ready brief: each milestone has a target, a checker and a deadline, locked by a hash"]
    ready --> held["Backers pre-order or fund milestones; the money is held on Solana until the proof passes"]
    held --> proof["The maker sends the proof: GitHub-signed checks, verified on chain, or 2 of 3 referees"]
    proof -->|verified| paid["The maker is paid for that milestone"]
    proof -->|not verified in time| back["Nobody is paid; the money goes back to the backers"]
    paid --> record["Each payment and refund is kept in the Knos record in Sibyl, anchored on Solana"]
    back --> record

No money locks on a vague brief. Each step is paid only when its proof is verified.

  1. Check demand. A demand check asks Qloo's taste data who would buy the product and where. Qloo's heatmap names the launch city.
  2. Ready brief. That city and the pre-order target its Qloo affinity sets become the brief's terms, inside its criteria hash. If the city falls short by the first deadline, every pre-order is refunded.
  3. Money held. Pre-orders and milestone funding wait in a program on Solana, not with Knos.
  4. Paid on proof. A pull request's checks pass and the program pays. Example: an agent was paid 5 test units for verified work on devnet. Released by the referee's verdict. The newest payout, read from chain, says what released it.

Add Knos to Claude Code with one command: claude mcp add --transport http knos https://knos.onrender.com/mcp

An agent with a capped key from Knos puts {"mcpServers":{"knos":{"type":"http","url":"https://knos.onrender.com/mcp","headers":{"Authorization":"Bearer ${KNOS_AGENT_KEY}"}}}} in .mcp.json and the key in KNOS_AGENT_KEY.

Open call: have research waiting for a market? Cross it on Knos: the page counts every crossing and pre-order by people outside Knos, live.

Paid on proof: when the proof is a pull request

The same held money pays for code. One comment on a GitHub issue posts the task, your checks and the pay (/knos fund 20 checks: test); an AI agent or a person sends the work as a pull request; when the checks pass and you merge, a program pays the worker.

flowchart TB
    task["You post a task, your checks and the pay; the money is held on Solana"] --> work["An AI agent or a person sends a pull request"]
    work --> checks["GitHub runs your checks and signs what ran"]
    checks -->|pass, and you merge| paid["A program on Solana checks GitHub's signature and pays the worker"]
    checks -->|fail| back["Nobody is paid; at the deadline the money comes back to you"]

You set the rules first. The money moves only when the work passes them.

Try it in ten seconds

Open the demand check in your browser. Type what you are about to build, or press one of the samples. Qloo's taste data says who wants it, where to launch it and at what price.

To check an AI agent's pull request instead, it has its own page.

There is nothing to install and no sign-up.

Why nobody can fudge the count

GitHub (where your code lives) signs a token for each run of your checks. The token proves which workflow ran, on which commit. Nobody else can make it.

A workflow is the script that runs your checks. A commit is one saved version of the code.

You and the other side each keep a copy of those signed runs. Each side rebuilds the bill from its own copy (the command is knos meter reconcile).

The two bills match line for line, so neither side can change the count alone.

The money waits in a program on Solana, not with Knos. That program checks GitHub's signature before it pays. Today one person can still change that program, after a public wait (who holds the keys).

Today Knos earns its fee only when work is accepted. When you get a refund, the fee goes back to you. So Knos gains when work passes, and the meter is not yet fully neutral (what is enforced and what is a promise).

Why Solana: Money is released with no custodian, and neither buyer nor supplier can change the count. One person holds every upgrade key today; a program change waits 8 days in public. A custodian is a company that holds your money for you.

Is it real?

It runs on test money only: test USDC on Solana's practice network, devnet.

There are no customers yet. Nobody has bought anything (what is not real yet).

One person holds every key today. Any change to the programs waits in public for 8 days first (who holds the keys).

WhatTodayRead from
This copyRelease 0.4.0, October 2026. A copy naming an older release, or another product, is out of dateCHANGELOG.md; the newest: PyPI
Reproduced by someone else0 of 267docs/reference/CAPABILITIES.md, the rows "reproduced by someone else"
Exercised at the public devnet program ids26 of 267: GitHub token verification, funding by one comment, funding from a wallet, pay on merge, refund at the deadline, pause, work orders, an order paying up to four payees, orders judged by the buyer's black-box tests, auto-accepted orders, a holdback released after its warranty, top-ups, single-use tokens, one counted evaluation, a counted batch of evaluations, the seller's own count, a payee's passkey wallet, a passkey funder, the passkey relay, the site's Buy page, an x402 order, the upgrade gate, strict JSON in the verifier, an outcome that is not code, ES256 tokens in one transaction, the presentation gracedocs/reference/CAPABILITIES.md, the rows "exercised on devnet"
Deployed at the public devnet program ids, no transaction recorded3 of 267: GitLab token verification, the key guardian, holding pay for a payee with no walletdocs/reference/CAPABILITIES.md, the rows "deployed on devnet"
Tested here only234 of 267, each with the test its row namesdocs/reference/CAPABILITIES.md, the rows "tested locally"
Written, not tested4 of 267docs/reference/CAPABILITIES.md, the rows "implemented"
Outside funders0docs/NUMBERS.md, row 1
Outside repositories0docs/NUMBERS.md, row 2
Outside payees1, on tasks Knos funded itselfdocs/NUMBERS.md, row 3
Payments between unrelated accounts3, on tasks Knos funded itselfdocs/NUMBERS.md, row 4
Buyer interviews held0docs/NUMBERS.md, row 5
Letters of intent0docs/NUMBERS.md, row 6
Reproductions signed by GitHub0docs/NUMBERS.md, row 7
Outside programs reading the verifier0docs/NUMBERS.md, row 8
Shadow counts published0docs/NUMBERS.md, row 9
Paying customers0docs/reference/DISCLOSURE.md
Revenue0; test USDC is not moneydocs/PRICING.md
Outside security reviewnonedocs/reference/ASSURANCE.md
Key holdersone person holds every key; an upgrade waits 8 days in publicdocs/reference/GOVERNANCE.md
Network and moneySolana devnet, test USDC; mainnet is not toucheddocs/reference/SECURITY.md

Check every claim yourself

Start at the release page: the code, how it is built, what runs on devnet, the payments and the fees.

One task from start to end, on 9 Oct 2026 with Knos 0.3.23, in a repository Knos owns, with test USDC (one step fixed by hand): funded · wrong work refused · paid (by the order's own black-box checks, with no merge) · replay paid nothing more · the record.

Rebuild knos_oidc and knos_pay, the programs that check the proof and pay, and compare: the hash devnet runs equals the verified build hash recorded for each (PROVENANCE). Read on 27 Oct 2026.

solana-verify get-program-hash -u devnet FkwZdsYCmzicJMtHLTkPK76bYNVG4WNwkWJBiVWNtF3W   # knos_oidc: a2df952d262c48edacf2f594a01321e805c28f1dc523cb6efa75f2c45f34e632
solana-verify get-program-hash -u devnet 5y7iWJ1VAMJjnnWbbdo2a2PsWJEwTExSNpzrvQSEnS8k   # knos_pay: 8b3c044024eac6e00cf10930c325465d5682c3fb7273fe2f0d59c6e01f99867c

Every capability, with the file or transaction that shows it: docs/reference/CAPABILITIES.md.

The number

Knos read 241 merged pull requests by AI agents whose description said the tests pass. In 9 of them, a test, build, lint or type-check job had failed at the last commit (3.7%; the true share is very likely between 2.0% and 6.9%; docs/backtest.json). 19 had a failed check of any kind (7.9%).

A first, automatic scan counted 16 and 30. A person then re-read each one and took out 11 of the 30: they were not merged into the main branch, or the failure or the claim did not hold (docs/index_review.json, method version 1, counted by scripts/backtest.py).

A second, larger count: in 147 of 826 repositories (17.8%), the first such pull request by an AI agent had a failed check of any kind (docs/reference/BENCH.md). A failed check is GitHub's record, not a judgment of why it failed.

Words

Pull request, devnet, multisig and more, each in one plain line: docs/WORDS.md.

Questions

What is Knos?

Knos takes research from a paper to a product people want. It pays each step only on verified proof.

How does Knos pay an AI agent?

You post the task, your checks and the pay before work starts. When the checks pass and you merge, a program pays the agent.

Does Knos use real money?

No. It runs on devnet, Solana's practice network, with test USDC worth nothing.

What does Knos cost?

Ten demand checks a month are free; releases will cost companies 1%. Today devnet charges 0.30%, at least 0.05 test USDC.

Who holds the money?

A program on Solana holds it, not Knos. Today one person can change that program, after a public wait.

Can the buyer refuse to pay?

Not once the checks pass and the work is merged. Before that, the buyer still chooses whether to merge.

Who keeps the count of accepted work?

Neither side alone. A program checks GitHub's signature of which workflow ran, on which commit.

How do I try Knos?

Open the front door and type the product you want to build. It says who wants it and where, with no sign-up.

Read more

uvx knos shadow invoice.csv: the same check from a terminal, on a bill of your own (it needs uv, a tool for Python).

  • Get started: check demand, write a Ready brief, then check a pull request and fund a task.

  • Pricing: what Knos costs. Demand checks are free, 10 a month. The solver keeps 100%; the company pays the 1% release fee and the payment costs on top. Nobody is charged today.

  • Trust: who holds the keys, what is tested, and what is not.

  • The story: one task in seven steps, each with its evidence.

  • Every other document: the map of the documents.


Contact: open an issue, or report a security problem privately: SECURITY.md.

Below: tables that scripts write from the code and the chain, and the licence. Nobody types them by hand.

programaddresson devnet, as docs/capabilities.json records it
knos-oidc, the verifierFkwZdsYCmzicJMtHLTkPK76bYNVG4WNwkWJBiVWNtF3Wruns 2.2
knos-pay, the payment program5y7iWJ1VAMJjnnWbbdo2a2PsWJEwTExSNpzrvQSEnS8kruns 2.2
knos-meter, the countFUMKkcE95x2kZUj1zZTCbgcYBmJ3WXPHL8pyA8J6anXruns 1.1
knos-passkey, a wallet from a passkeyFQPX9i5kQxLYKZyyPgM2fVK9am3w1LSk1Cuoer1sSY85runs 1.1

Every program the app or this site uses, and who can upgrade it, read from devnet on 2026-10-26 (scripts/program_authorities.py):

programaddressused forupgrade authority
knos-pay 0.3.34: the app's live program (0.3.34)FaMHCjzyUexFncZrmNyFQNz3gBdsLbhTLke7QBFykJY4every pre-order, milestone payout and agent payout of the appCKCrTBN542pVhizxuSPVg8tvdnPooNxt9B7o97VuTjz2, the Squads vault (an upgrade waits out its 8-day time lock)
knos-oidc 2.2: the verifier of GitHub's signed checksFkwZdsYCmzicJMtHLTkPK76bYNVG4WNwkWJBiVWNtF3Wpay on merge, the site's signature lineCKCrTBN542pVhizxuSPVg8tvdnPooNxt9B7o97VuTjz2, the Squads vault (an upgrade waits out its 8-day time lock)
knos-pay 2.2: the payment program5y7iWJ1VAMJjnnWbbdo2a2PsWJEwTExSNpzrvQSEnS8kpay on merge, the site's work ordersCKCrTBN542pVhizxuSPVg8tvdnPooNxt9B7o97VuTjz2, the Squads vault (an upgrade waits out its 8-day time lock)
knos-meter: the countFUMKkcE95x2kZUj1zZTCbgcYBmJ3WXPHL8pyA8J6anXthe meter on the siteCKCrTBN542pVhizxuSPVg8tvdnPooNxt9B7o97VuTjz2, the Squads vault (an upgrade waits out its 8-day time lock)
knos-passkey: a wallet from a passkeyFQPX9i5kQxLYKZyyPgM2fVK9am3w1LSk1Cuoer1sSY85passkey wallets in the appCKCrTBN542pVhizxuSPVg8tvdnPooNxt9B7o97VuTjz2, the Squads vault (an upgrade waits out its 8-day time lock)
knos-hook: the transfer hookAFQFtodihz5jAHpVBUk87AkH8FJsQdmHt8Z5NKLWRj1Tthe app's Token-2022 project creditsCKCrTBN542pVhizxuSPVg8tvdnPooNxt9B7o97VuTjz2, the Squads vault (an upgrade waits out its 8-day time lock)
knos-oidc, first deploymentvpWym9azbPU5f2PH2a6n8c4RfmsyUeW2dMuWr1DSHcEthe site's history of the first deploymentnone: nobody can change it
knos-pay, first deployment9UzPFbh2A4e4sEPgngKG523FfYLnQ3qPfFVfFTTAdfDithe site's history of the first deploymentnone: nobody can change it
SPL Record (Solana)recr1L3PCGKLbckBqMNcJhuuyU1zgo8nBhfLVsJNwr5the app's chain-state records7VaWK6qq7WLBiMQ8TTAGwrFJfAekAwra4UPKr4S5UNjB, one key
SPL Memo (Solana)MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHrthe app's fee estimate and its notes on chainnone: not an upgradeable program
Token-2022 (Solana)TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEbthe app's project credits3URRPr96EV2wuNRgQKwQpuZitHHsVyDUen1eRSvEun9G, one key
Squads multisigSQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCfthe upgrade and guardian vaultsHM5y4mz3Bt9JY9mr1hkyhnvqxSH4H2u2451j7Hc2dtvK, one key

This page names no time for an upgrade, so it stays true before and after one. To see whether a change to the programs is waiting, done or withdrawn, run knos status, or read the site's banner or its upgrade record (web/upgrades.json is the copy kept here).

The first set of programs (programs) has no upgrade authority, so nobody can change it. It stays as a record, and no new task is funded there.

Reproduced by someone else: none recorded yet. Exercised on devnet: verify_github, fund_by_comment, fund_from_wallet, pay_on_merge and more, each named in the table. Deployed on devnet: verify_gitlab, key_guardian, hold_and_bind. Everything else is tested locally, implemented or not built: the table with the evidence has one row for each capability, from docs/capabilities.json. Only runs at the public program ids count here. Each capability's row also notes, with its transaction, any earlier trial run at separate test addresses (Knos 0.3.14).

MIT licence, all of it. Built by drexthealpha. Everything Knos remembers is kept by the Sibyl memory engine.

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.