Intentra

Demo

About

Intentra is a decentralized service marketplace , framed as an "AI Commerce Protocol." Here's how it works: AI-driven matching – you describe what you need and your budget, and an AI parses your intent to find a matching service provider, with the arrangement secured by EIP-712 cryptographic mandates (structured, signed data commitments). Human verification – providers must prove they're real humans (not bots) using World ID's "World Selfie Check," aiming to eliminate scams and fake accounts. Escrowed payments funds are held in USDC via a smart contract escrow on the Arc testnet, only releasing to the provider once the job is completed and approved by the client. In short, it's a trust layer for hiring freelancers/service providers where an AI agent handles the negotiation/matching, identity is verified cryptographically, and payment is escrowed on-chain until work is confirmed done.

How it's made

The backend is a FastAPI modular monolith, organised domain-per-package rather than by layer: intents, providers, transactions, authorization, payments, fulfillment, evidence, disputes, identity and audit each own their router, models, schemas and service. Boundaries are not a convention here, they are CI — 14 import-linter contracts fail the build if a domain touches another domain's tables, if the shared kernel imports a domain, if an adapter reaches back inward, or if pure rule code (money, hashing, state machine, policy) imports FastAPI, SQLAlchemy or web3. The one deliberate exception is the Transaction aggregate root, and a test walks the source tree to prove the state machine is its only writer. SQLModel/SQLAlchemy async over asyncpg, Alembic migrations, 20 tables. Three worker loops (chain watcher, transaction outbox, reconciliation) run in-process, guarded by a Postgres advisory lock so only one instance is leader and the same code scales to several replicas untouched. 572 tests. ON-CHAIN IntentraEscrow is Solidity on Arc testnet (chain 5042002), built with Foundry. Two rules drive the whole design: money states commit only on confirmed chain events, never on an optimistic write, and settlement needs two distinct signatures from {customer, provider, AI arbitrator}. The watcher reads eth_getLogs from the escrow's deploy block, advances a cursor only after every log in a range is handled, and keys events on (tx_hash, log_index) so a replay after a crash is a no-op. Outbound calls go through an outbox: rows are claimed with SELECT ... FOR UPDATE SKIP LOCKED, the transaction hash is committed to the database before we wait for a receipt, and one lock serialises the resolver's nonce. PARTNER TECHNOLOGIES Arc — escrow and settlement in USDC, with gas paid in USDC too, which removes the "buy the native token first" step that kills onboarding for the Nigerian users this targets. Deterministic finality let us run the watcher at 1 confirmation. Privy — email login to an embedded wallet, so a customer signs an EIP-712 mandate without ever seeing a seed phrase; also signTypedData and sendTransaction for the escrow calls. Access tokens are ES256-verified server-side against the app's verification key. World — Selfie Check proof-of-human gates authorisation and complaint, the two places fraud pays. One nullifier per action per transaction, so a proof cannot be replayed onto another job. The Graph — a subgraph over the escrow's own events turns completed, disputed and refunded jobs into provider trust scores, so reputation comes from chain history rather than rows we could edit.