DEV Community: Christopher Poulsen

Earn and spend USDC on inference

Christopher Poulsen — Wed, 21 Oct 2026 02:33:46 +0000

If your app or harness talks to three model providers, you have three accounts, three API keys, three billing dashboards, and three sets of rate limits to babysit. If you want to offer a model, you need your own signup flow, key issuance and billing before anyone can pay you.

We've been building Stellarium, a decentralized network where anyone can host an API and get paid for every call. This post is about the newest piece: running AI inference on it. Models become ordinary resources on the network, callers pay per token in USDC, and nobody needs to set up an account.

A model is just a resource

On Stellarium, every API is a resource hosted by a node. A resource has a name, like com.example.Weather, and a list of functions programs can call. Nodes advertise their resources to peers, and any node can route a call to whoever hosts the resource.

An AI model fits the same shape. A provider wraps the model in a resource with a function that takes a prompt and returns text. For example, sh.stellarium.inference.claude.Sonnet exposes Claude Sonnet through a message function.

That means AI gets everything the network already does: discovery by name, routing between peers, results that carry either a value or an error, and payment with no signup or keys.

Calling a model

Requests on Stellarium are written in RequestScript. Calling a model looks like calling a function. The only difference is maxTokens is a required parameter. This allows the caller and provider to work out a fair price.

request AskClaude {
  const sonnet: sh.stellarium.inference.claude.Sonnet

  const reply = sonnet.message(prompt: "Write a haiku about Oslo", maxTokens: 200)
  if (reply.error != null) {
    return reply.error.message
  }

  return reply.value
}

The node does the rest: it finds the node hosting the model, gets a price estimate, checks it against your spending limit, and pays for the call. If the model fails, your script gets an error it can handle rather than a dead request.
Since a model is just another resource, one request can mix a model call with anything else on the network (a weather lookup, a Regex validation) and combine the results.

The hard part: paying per token, fairly

Most paid functions on Stellarium charge a flat fee per call. That doesn't work for inference, because cost depends on input and output tokens. There's a trust problem in both directions:

The caller can't know the output length ahead of time, and doesn't want to sign a blank check.
The provider doesn't want to burn GPU time (or its own API credits) on a call that won't be paid.
Nobody should have to trust the provider to report whatever token count it likes. AI-based functions need a new function type: inference functions. Inference functions are priced at a rate per million input tokens and a rate per million output tokens.

Every paid call goes through six steps:

Estimate. The caller's node asks the provider for an estimate. The provider counts the input tokens and returns maxAmount: the cost of those input tokens plus maxTokens of output.
Check. The caller recomputes maxAmount from the advertised rates and refuses the call if it's over its configured limit.
Sign. The caller signs an inference voucher carrying maxAmount, both rates and maxTokens, and sends it with the call.
Verify. The provider checks that the voucher's rates and maxTokens match, re-runs its estimate, and answers 402 if the voucher doesn't cover it. Inference never runs unpaid.
Report. After the call, the provider sends the voucher and actual token counts to the operator. Output is capped at maxTokens.
Settle. The operator verifies the signature and charges actual usage at the signed rates, never more than maxAmount, settling on Solana through an escrow.

The caller agrees to a ceiling up front and pays only for what was used. The provider knows the call is covered before spending anything.

Why this matters for agents

Agents have a great use-case for Stellarium. An agent that wants a second model, a cheaper model for a subtask, or a specialized model someone else fine-tuned shouldn't need a human to sign up, paste an API key and attach a card. On Stellarium it calls the resource by name, its node enforces a hard spending ceiling per call, and the payment is settled automatically. All through USDC on Solana.

Try it

Read the AI overview and the inference functions guide:
- https://stellarium.sh/ai
- https://stellarium.sh/ai/inference-functions
Browse models and their rates on the registry: https://stellariumregistry.xyz/
Run a node and host your own model
Star or contribute on GitHub
Come say hi on Discord. If you host a model, we'd love to hear about it.

Payments on Stellarium go live this Thursday, October 22nd, 2026. Stellarium is open source and early. Questions, comments and pull requests are all welcome.

https://stellarium.sh

RequestScript & Stellarium - A new way to build web APIs

Christopher Poulsen — Mon, 05 Oct 2026 02:06:44 +0000

Hey everyone! I'm introducing two new projects I have been developing the past few years that I think are now ready for primetime and more contributors.

TLDR: RequestScript is a new programming language that is declared in the request body to an HTTP server. Stellarium is a decentralized API platform that runs RequestScript and handles API monetization.

What is RequestScript

RequestScript is a programming language that is declared in the request body to a server. It is influenced by Kotlin and Typescript:

// sent to http://localhost:3000/run
request MyRequest {
    const a = 2
    const b = 3
    const c = a + b

    return "Hello World!"
}

You can define Resources in the host language and reference them in RequestScript.

In Typescript:

import type { Resource } from "requestscript-js";


const addResource: Resource = {                       metadata: {},
      path: "path.to",
      name: "AddResource",
      functions: [
        {
          name: "add",
          parameters: [
            { name: "first", type: "int32" },
            { name: "second", type: "int32" },
          ],
          returnType: "int32", 
    // any RequestScript type string, or 'void'
          exec: async (
    args
    ) => {
            const first = args.find((
    a
    ) => a.name === "first")!.value as number;
            const second = args.find((
    a
    ) => a.name === "second")!.value as number;
            return first + second;
          },
        },
      ],
    };

In RequestScript:

request MyRequest {
        const math: path.to.AddResource
        return math.add(first: 2, second: 3)
    }

You can also define reusable requests called Contracts that are saved to the server and can be executed on demand.

In RequestScript:

contract path.to.MyContract@1.2.3(name: string) {
        return "Hello ${name}"
    }

Stellarium is where things get really interesting.

What is Stellarium?

Stellarium is a decentralized API platform that allows anyone to execute RequestScript and call server resources and contracts across a network. You can effectively call resources and combine their output across nodes hosted in different languages. It's really simple to create Resources and share them. Hate dealing with HTTP status codes, retry logic, etc.? Craft your APIs in RequestScript Resources instead. Have a favorite library in Go you wish you could call in Java? Export it as a Resource in the Go node, and call it on the Java node in a typed way using RequestScript. The goal is for a global, decentralized API network.

Monetization

Stellarium also makes API monetization easy, as the individual RequestScript tokens you use can be totaled up and sent to its controlling node for payment. Only pay for the exact if statement you execute, or resource function you call.

If you're interested in contributing or learning more, here are the repos:

All experience levels welcome! This could be an especially helpful project for anyone wanting practice in writing spike docs and RFCs. Everything is just getting off the ground and is very much a work in progress. More documentation coming soon!

Guide: Running an Avisen node

Christopher Poulsen — Wed, 19 Mar 2025 21:37:11 +0000

The official Avisen client is deployed to https://hub.docker.com/repository/docker/avisen/client-kt/general.

For starting out, we recommend connecting with an official test network or starting your own. See boot nodes for official boot node addresses.

Running the first time

Docker Compose

We recommend running a node using Docker Compose. This will help automate the start-up of the database and node and make it easier to set the client’s many environment variables.

Choose a node type

An Avisen node can start in many different nodes:

UTILITY: a node that is running without a blockchain, network, or database. Useful for generating key-pairs and working with Avisen's local utilities. Most REST API endpoints are disabled in this mode, but you still get access to the crypto utilities. A database is not used in this mode.

REPLICA: a node that is a full replica of the network and blockchain. Receives updates from publisher nodes.

PUBLISHER: a node that has the ability to publish transactions (articles), mint blocks, and broadcast new blocks to the network. Requires ECDSA signing keys and permission from the blockchain to publish.

Choose run behavior

An avisen node can start up its own blockchain or join an existing network. This is handled by the optional BOOT_NODE environment variable. If it is set, the node will attempt to join the boot node’s network and download its blockchain. If it is not set, the node will start its own blockchain with a Genesis block.

Prepare the database

Running a non-utility node requires a running PostgreSQL database at version 17 or higher.

The chosen database user must have permissions to create tables, insert data, and select data in the default schema. This can be done by connecting directly to the database and running the following commands:

GRANT ALL PRIVILEGES ON DATABASE YOUR_DATABASE TO YOUR_USERNAME;

GRANT ALL ON SCHEMA public TO YOUR_USERNAME;

Fulfill environment variables

The client requires many environment variables. It is important to take note of which ones are required for the mode you are running your node in.

DB_URL: the url corresponding to the backing PostgreSQL database. There should only be one database per node. Not required in UTILITY mode.

DB_USER: the username when connecting to the database. This should not be the admin user. Not required in UTILITY mode.

DB_PASS: the password for the database user. Not required in UTILITY mode.

NODE_ADDRESS: the url address (host, port, etc.) for accessing the node. Broadcast to the other nodes in the network. Required. This should be a static IP address or url.

BOOT_NODE: the url address (host, port, etc.) for accessing another node to populate the blockchain and network pool. If not populated, the node will run in genesis mode. (See Network/Starting up for the first time) Not required in UTILITY mode.

NODE_MODE: the mode to run the node in:

PUBLISHER: a node that has the ability to publish transactions (articles), mint blocks, and broadcast new blocks to the network.

REPLICA: a node that is a full replica of the network and blockchain. Receives updates from publisher nodes.

UTILITY: a node that is running without a blockchain, network, or database. Useful for generating key-pairs and working with Avisen's local utilities. Most REST API endpoints are disabled in this mode. Database connection information is not required in this mode.

NETWORK_ID: a shared id that prevents cross-network activity. Not required in UTILITY mode.

PORT: the given port for the app to run on. Defaults to 8081 if not provided. When running in Docker, the port must be set to 8081.

PUBLISHER_SIGNING_KEY: A private ECDSA key used for signing blocks. Required if running a node in PUBLISHER mode. Not required in UTILITY mode.

PUBLISHER_PUBLIC_KEY: A public ECDSA key used as property of a block. Required if running a node in PUBLISHER mode. Not required in UTILITY mode.

Start the app!

Start the node using your preferred Docker method. Check the logs for errors and success. If you are having trouble starting a node, head over to our official Discord server for help.

Connect to the node

See this guide for more information on how to connect to a node. Log issues to our github page or our discord.

Call for Contributors

Christopher Poulsen — Wed, 19 Mar 2025 00:04:58 +0000

Hey everyone! I’m looking for more contributors for my open source project: Avisen. If you’re interested in Kotlin, Go, decentralized networks, blockchain, or supporting independent journalism, check out our website or join our discord!