
Velum
Verify delivered work against private terms with Chainlink CRE before releasing one payment.
Demo
About
A successful build does not prove a contractor delivered the agreed software revision. Velum verifies that boundary before releasing a work-order payment. A payer’s work order specifies the accepted revision, recipient, payment amount and budget. When delivery is submitted, Velum reserves the work order and uses Chainlink CRE to retrieve live GitHub evidence and evaluate it against the configured acceptance record and commercial terms. The resulting authorization determines whether a Solidity treasury can pay. The interactive demo shows two real, successful GitHub workflow runs. The earlier revision fails the acceptance check: payment is held and zero tokens transfer. The accepted revision passes and releases 2,400 test tokens. Payment history survives a reload, concurrent requests cannot reserve the same work order, and another attempt to pay the completed order is rejected. Confidential Workflows are central to the design: credentials, source records and payment-policy evaluation belong inside the confidential handler, while the public ABI authorization omits raw commercial terms. This is a prototype with synthetic commercial terms and team-configured acceptance. It demonstrates actual CRE CLI simulation and live GitHub retrieval. Settlement runs in a persistent, journal-backed local EVM with a mock forwarder; the primary flow does not send a network payment or demonstrate deployed TEE attestation.
How it's made
Velum combines TypeScript, Zod, Chainlink CRE, Solidity and Cloudflare Workers. A browser interface submits delivery evidence to a Worker API. SQLite-backed Durable Objects reserve the work order and budget, queue execution, and persist payment history. The CRE workflow registers handlerInTee. Inside that handler, it retrieves separate source and GitHub credentials, fetches the work-order record and live GitHub evidence, and checks the accepted commit, numeric repository and workflow identities, branch, trigger, successful completion and pinned workflow definition. These checks run alongside the commercial payment policy. Chainlink provides the workflow boundary for authenticated retrieval and confidential policy evaluation, making the resulting report the input to settlement. The workflow uses usingTheDons to return an ABI authorization without raw commercial terms. Our BatchTreasury contract checks its configured forwarder and workflow identity, request commitments, recipient, amount, token, chain and expiry before atomically consuming authorization and transferring ERC-20 test tokens. A VM runner executes actual CRE CLI simulations and feeds their report bytes into compiled Solidity running in EthereumJS. A notable implementation detail is the durable execution journal: it reconstructs each workspace’s local treasury from recorded operations, caches completed results and redelivers them until acknowledged. Uncertain executions retain their reservations, and recovery resumes the same job rather than opening another payment path. The project includes 58 unit tests, contract tests and deployed browser checks covering held and paid outcomes, concurrent reservations, reload recovery and duplicate protection. Local execution uses mock forwarding and does not establish deployed enclave attestation. Work-order uniqueness relies on the reservation service and journal; the contract independently prevents request replay. Codex generated the implementation, tests, interface and drafts. Lawrence selected the Chainlink focus, configured and authenticated the development environment, chose Velum’s identity and artistic direction, reviewed iterations and authorized the product direction.