ChainSQL is building a PostgreSQL integration layer for connecting business records, controlled payments, and paid API requests—with Odoo as the first reference integration.
Working on an ERP integration? Request a pilot conversation →
ChainSQL installs into PostgreSQL and is called with ordinary SQL. It records the intent—what should be paid or purchased, for which business record, under whose authority—and hands the network work to a separate execution service.
Associate an invoice or business operation with its payment request, status, and receipt.
Every request carries a reference back to the record that produced it, so the payment trail stays attached to the work instead of living in a separate system.
Let authorized workflows and agents request paid resources within defined budgets.
Limits and permissions are evaluated by the execution service against policy you configure—not by the request, and not by the model that proposed it.
Preserve document versions and integration outcomes, with optional blockchain commitments.
Documents stay in your own storage. Only the information you explicitly select is committed on-chain for verification.
A SQL call inside PostgreSQL checks the caller and enqueues an operation with a stable identifier. No key material is involved at this stage, and no network call is made.
The execution service holds signing authority, applies spending policy, submits the operation, and records the outcome it observes. It runs outside the database process.
The observed outcome is written against the original operation. The database transaction and the blockchain transaction have separate lifecycles, but they are not independent: a payment retry preserves and reuses the original authorization, and reconciliation confirms what the network actually did before anything is re-sent.
This is the demonstration we are building. It shows how an existing ERP flow could route a payment decision through ChainSQL while the accounting work stays in Odoo.
Illustrative workflow
A vendor bill is recorded the way it is today. Nothing about the ERP entry point changes.
Authorized data is gathered with SQL: prior bills from the same vendor, purchase orders, receipt confirmations, and any attachments already stored.
The recommendation and its stated rationale are stored against the operation, so a reviewer can see why a decision was proposed.
Amount, vendor history, budget, and duplicate signals are evaluated by policy outside the model. The outcome is either permission to execute or a request for human approval.
The approved operation is written into PostgreSQL as a pending request with an identifier used for tracking and reconciliation.
Outside the database, the service signs and submits the transfer, then observes the result. This is the part designed to run on Arc testnet first.
The observed outcome and its reference are written against the originating operation and shown to the ERP user.
Two different jobs, handled by two different mechanisms. ChainSQL integrates with each separately, and neither one depends on the other to work.
Arc is an EVM-compatible Layer-1 blockchain designed for stablecoin applications, where transaction fees are paid in USDC. For business payments that matters: the asset being moved and the cost of moving it are denominated in the same stable unit.
ChainSQL’s planned Arc integration is designed to execute approved stablecoin payments and associate the resulting transaction with the ERP record that requested it.
x402 is a payment protocol for APIs and other online resources. A compatible service can communicate its payment requirements; an authorized client can prepare a payment and obtain the resource through the protocol.
An ERP agent needs to confirm a new vendor. Mid-workflow it purchases a supplier verification report using x402, and later a logistics data lookup for the same order—each within the budget the workflow was granted.
The planned integration checks payment terms and available budget before a request is prepared, then records both the resource result and the payment outcome against the business operation. It could also work in the other direction, letting a business charge for access to explicitly authorized API resources.
x402 handles the resource-payment exchange, while a supported blockchain handles settlement. Ordinary invoice transfers do not automatically become x402 transactions—the two paths are separate by design.
ChainSQL is called with ordinary SQL from the application you already run. The scaffold ships the extension, the worker, and an Odoo addon skeleton so the request-and-result cycle can be exercised end to end on your own machine.
SELECT chainsql.request_resource(
'supplier-verification',
'{"vendor_id":42}',
'vendor_check_00000042'
);
SELECT id, kind, state, result
FROM chainsql.operations;Queue a request to an administrator-configured resource, then inspect its status. The scaffold’s mock worker simulates execution.
The scaffold runs on your own machine. The mock worker does not contact a network or spend funds—it exists so the request-and-result cycle can be developed before live execution is wired up.
Signing and network execution sit outside PostgreSQL. The database records intent and results; it does not hold keys or talk to the network.
These are design intentions, not completed guarantees. Some are partly implemented in the scaffold.
Designed to run inside infrastructure you control, next to the database it extends, without a required hosted dependency.
Invoices, bills of materials, and attachments live in your infrastructure. The starter supports storing document bytes locally alongside their hashes, so a document can be verified without leaving your systems.
What gets committed is chosen deliberately, field by field. There is no default that publishes business data.
Budgets, limits, and approvals are evaluated by policy code in the execution service. A model can propose an action; it cannot authorize one.
Every request carries a stable identifier, and a retry preserves the original authorization. Recovery logic reconciles a repeat against the first attempt instead of recording a second obligation.
The ability to call the extension, the ability to run execution work, and the ability to sign are intended to be distinct roles held by different processes.
ChainSQL is an early-stage project. The first column is available now; the rest is what we are building.
Pilot conversations begin with a single flow—a vendor bill approval, a data lookup, an agent that needs a spending limit. We work through how it maps onto the extension, what the scaffold covers, and what it does not yet.
One email, straight to the maintainers. No signup, no account.
It adds a connection between a business record and a payment or purchase operation. A bill, order, or workflow action gets a corresponding request with a status, an outcome, and a reference back to the record it came from—plus a place to record commitments for verification.
Your ERP keeps doing the accounting. ChainSQL handles the request, the network step, and the link between them.
Odoo is widely used, self-hostable, and built on PostgreSQL—the database ChainSQL targets first. That makes it the shortest path to showing the idea end to end, with real invoices and real approval steps instead of a synthetic demo.
It is a reference integration, not the limit of the design. Additional ERP connectors are a future direction.
What you explicitly choose. Documents are stored locally, and the scaffold supports storing document bytes in your own storage alongside their hashes—so verification does not require publishing the document itself.
Anything written to a public network should be treated as public, so ChainSQL does not promise privacy for information you elect to publish.
They solve different problems. x402 negotiates access to a paid resource over HTTP—the protocol layer for buying something. Arc is where stablecoin value settles—the settlement layer for moving it.
A single workflow can use both: purchase a data lookup through x402, and settle a vendor payment on Arc. Each is recorded against the relevant business operation.
The starter scaffold. It runs locally and simulates execution—no funds are spent and no live network is contacted.
Live Arc settlement and the complete Odoo payment workflow are still ahead. Request a pilot conversation if you would like to look at it against your own workflow.