Search projects, hackathons, sponsors and tech

    ← All projects

    Tessera_Marketplace

    Rent compute by the block. Pay for each block before it runs. Settled on Hedera via x402.

    Demo

    About

    Tessera — rent compute by the block, pay for each block before it runs Tessera is a marketplace for renting a running container from a provider you've never met, where time is cut into fixed blocks and every block is paid for on Hedera before it is served. The problem. If you rent compute from a stranger, one of you has to go first. Either the provider serves you on credit and hopes you pay — and an AI agent can drain them and vanish — or you post a deposit into escrow and hope they deliver, which is the custody model that crypto payments were supposed to make unnecessary. Somebody is always exposed. x402 doesn't solve this, because x402 is request-shaped: one request, one price, one payment. Compute isn't discrete — a container consumes resources continuously while payments trail behind it. The Block Settlement Protocol (BSP). Our answer, specified in full in SPEC.md, is to divide time into fixed blocks (say 15 seconds), require each block to be paid before it begins, and open the window to buy block n+1 while block n is still running. That lookahead window is the whole trick: it absorbs the few seconds a payment takes to settle, so service is continuous while neither side ever extends credit. Four invariants fall out, and they are the design: 1. No credit. The block being served is always already settled. The provider never works unpaid. 2. Bounded renter exposure. The most a renter can lose to a provider vanishing is one block — 15 seconds of compute. 3. Deterministic termination. Stop paying and the container stops at the next boundary. Not early (a payment may still land), not late (that would be unpaid work). No grace period, no negotiation. 4. No custody. Payment goes renter to provider directly. Our marketplace does discovery and placement, then gets out of the way — our test suite kills the control plane mid-job and the job keeps running and keeps billing. How it uses Hedera. Every block settles as a native Hedera transfer through the Blocky402 x402 v2 facilitator, in HBAR or in TESS, an HTS token we minted (0.0.10518829, 2 decimals, custom fee schedule). Every receipt is published to an immutable HCS topic (0.0.10507942, no admin key, no submit key) that anyone can audit through a mirror node without asking the provider — which is what makes a provider shortening blocks detectable rather than deniable. Every provider carries an HCS-14 on-chain identity derived from its metadata and payout account, and signs every receipt with it. The facilitator co-signs and pays the network fee, so the renter never holds gas and no contract ever holds funds. The protocol's 4-second lead-time floor is a measurement, not a guess: Blocky402's full paid leg (402 to sign to verify to settle to 200) takes a median 3.2s on testnet. What runs. A TypeScript pnpm monorepo: a provider daemon that runs Docker containers and enforces block boundaries; a registry/broker marketplace; renter and provider CLIs; a key-holding renter agent so the browser never touches a private key; an SDK (marketplace.rent() with block/renewal events and a stopRenewing() kill switch); and a console that reads the audit trail back from Hedera through a mirror node. 356 tests. Verified end to end on testnet: a renter bought a 20-block lease against a 10-block wallet, ten blocks settled on-chain one per block, block 11 was refused for insufficient funds, and the hosted website went from HTTP 200 to connection refused at exactly the next boundary — with all ten receipts plus the terminal unpaid_boundary receipt readable on HCS. Honest limits. It isn't deployed to a public URL, there's one provider node rather than a fleet, and we deliberately skipped multi-agent price negotiation. The settlement is real; the marketing is not.

    How it's made

    Tessera is a TypeScript monorepo managed with pnpm workspaces, organised into nine packages so that the protocol logic stays independent of the infrastructure around it. Shared packages hold the block clock, the x402 v2 wire types and the receipt schemas, validated with zod. A separate Hedera package wraps transaction signing, HCS publishing and mirror-node reads. On top of these sit the provider daemon, the registry and broker service, the renter and provider CLIs, a programmatic SDK and a web console. The services are built on Fastify with pino for logging, better-sqlite3 for local state and dockerode for container management. The console is React 18 and Vite 5. Tests are written with vitest. The provider daemon is the core of the system. The protocol rules are implemented as pure functions with no I/O: one module decides whether a block boundary advances or terminates the job, and another enforces the specification's minimum lead time. Above them sits a scheduler that ticks once per second across all active jobs and evaluates the boundary condition for each. It depends on a Clock interface rather than the system clock, so tests can drive it deterministically with a fake clock instead of waiting for real seconds to elapse. The Docker runner is abstracted the same way, which allows the full job lifecycle to be tested without Docker running. Payment admission follows the same pattern: a single pure function takes the job state, the block being paid for and the current time, and returns one of five decisions, including idempotent replay of a block that has already been paid. This keeps the entire error matrix unit-testable in isolation from the network. Hedera is central rather than incidental. Settling once per fifteen-second block is only viable on a network with fast finality and predictable, low fees. Each block is settled as a native Hedera transfer through the Blocky402 x402 facilitator, denominated either in HBAR or in TESS, an HTS token issued for the project. The facilitator co-signs and submits the transaction and pays the network fee itself, so the renter never needs to hold gas and no contract or intermediary ever takes custody of funds. Each settled block appears on-chain as a direct transfer from the renter's account to the provider's. Receipts are published to a Hedera Consensus Service topic created without an admin key or a submit key, making the log immutable and openly writable to participants. The console reads that history back through a public mirror node rather than from the project's own database, so the audit trail can be verified independently of the provider. Provider identity uses the HCS-14 standard, generated through the Hashgraph Online standards SDK, so that each provider has a verifiable on-chain identifier derived from its own metadata and payout account, and signs every receipt with it. One protocol constant was derived from measurement rather than estimation. The minimum renewal window is four seconds because the complete paid request through the facilitator, covering the initial 402 response, signing, verification and settlement, was measured at a median of 3.2 seconds on testnet. The registry rejects any listing configured below that floor so that a misconfigured provider cannot make the protocol appear unreliable. The most notable implementation workaround concerns two optional native modules, ssh2's crypto binding and cpu-features, both pulled in transitively through dockerode. On some hosts these segfault when loaded, which terminates the process at import time and cannot be caught in JavaScript. Because ssh2 already guards both of these requires and falls back to a pure JavaScript implementation, the build configuration deliberately excludes them, converting an unrecoverable crash into a handled error. The only capability lost is SSH cipher acceleration, which the project does not use, as the daemon communicates with Docker over a Unix socket. Containers are run with a read-only root filesystem, memory and process limits, restricted networking and no-new-privileges enabled by default, with a configuration flag to disable the last of these on kernels that refuse to exec under it. The daemon also refuses to start if it is configured to publish receipts to Hedera but lacks the topic or operator credentials, rather than running with an audit log that is silently empty.