Dileo helps a company present a purchase order as an attributable financing opportunity. It connects every material claim to its source, keeps uncertainty visible, gives an independent reviewer authority over the exact public Deal Blueprint, asks the named buyer to confirm that order, and routes capital through an explicit X Layer escrow lifecycle.
AI prepares the evidence. People approve the meaning. The contract controls capital.
| Product | AI-native purchase-order finance |
| Network | X Layer Testnet (1952) |
| Reference opportunity | Kora Exports — fictional commercial evidence |
| Test asset | DemoUSDC (dUSDC) — no monetary value |
| Public guide | /docs |
| Release evidence | Testing and release evidence |
- Open Explore and read the Kora opportunity without connecting a wallet.
- Open the deal and move through Overview → Blueprint → Evidence → Uncertainty → Intelligence → Funding.
- In Intelligence, choose a suggested question. It fills the input; press Ask to receive a grounded answer with evidence IDs.
- Connect the company wallet to create or resume a private deal and upload supporting PDFs.
- Connect the allowlisted reviewer wallet to inspect the private evidence and approve one exact Blueprint.
- Send the focused confirmation link to the named buyer. The buyer connects that deal’s assigned wallet and confirms the exact Blueprint.
- Connect any capital-provider wallet, claim test dUSDC, approve the contribution, and fund the escrow.
- Follow the onchain state through release, principal repayment, contributor claim, or cancellation and refund.
The presentation route, wallet order, expected screen state, and recovery steps are in the judge demo guide.
Small exporters can hold real purchase orders and still struggle to present evidence in a form a funder can review quickly. A normal funding card shows an amount and a return. Dileo shows:
- where each important claim came from;
- which values agree across documents;
- what is missing or conflicting;
- who approved the exact public representation;
- whether the buyer confirmed that exact order; and
- what the escrow contract permits next.
Dileo does not let AI approve credit, authenticate legal documents, move money, or promise repayment.
Dileo is not a collection of disconnected mock screens. The hackathon build is a working vertical slice of the intended product: a company-owned private draft becomes attributable evidence, an accountable reviewer freezes the public meaning, the named buyer confirms it, and capital follows a constrained escrow lifecycle. Fictional Kora records, test assets, and deliberately narrow permissions make that complete journey safe and repeatable for judges.
The product architecture is already shaped for the real operating model. What changes for production is the strength of identity, governance, compliance, custody, and operations—not the core journey.
| Area | Hackathon implementation | Production intent already mapped |
|---|---|---|
| Company / issuer | One verified wallet owns a private draft and submits six fictional Kora PDFs. | Verified organization accounts, delegated team signers, business onboarding, document integrations, retention controls, and legal identity checks. |
| Evidence Intelligence | One live Groq structured extraction is rechecked deterministically and persisted with source hashes. | Provider redundancy, continuous evaluation, monitored quality thresholds, richer document/authenticity services, human escalation, and versioned model governance. |
| Reviewer | One deployment-configured reviewer wallet can approve the exact Blueprint. This makes authority obvious and testable. | A policy-governed underwriting multisig with operations/risk threshold approval, reviewer registry and revocation, case assignment, audit trails, conflict controls, and separation from custody. |
| Buyer confirmation | The exact buyer wallet receives a focused link and confirms the registered Blueprint without creating a workspace. | Verified buyer organization, delegated authorized signers, notification and reminder channels, expiry and re-confirmation rules, plus appropriate electronic-signature and commercial-law controls. |
| Capital provider | Any connected wallet can inspect an approved public deal and fund with test dUSDC. | Jurisdiction-aware eligibility, KYC/AML and sanctions checks, suitability or accreditation where required, disclosures, limits, reporting, and servicing. Public transparency can remain while participation is policy-controlled. |
| Asset and escrow | Capped DemoUSDC and an X Layer Testnet escrow exercise registration, funding, release, repayment, refund, and claims. | Approved settlement assets, audited and capped contracts, production multisig administration, monitoring, pause/incident policy, accounting, reconciliation, and deliberate mainnet activation. |
| Commercial evidence | Kora, its counterparties, values, and all six PDFs are fictional and reproducible. | Real customer records accepted only after privacy, processor, authenticity, fraud, retention, and jurisdiction controls are operational. |
This distinction is intentional: judges can test the whole product thesis without Dileo pretending that a hackathon deployment is already licensed, audited, or ready to hold real commercial capital.
| Role | What the person does | Who can act |
|---|---|---|
| Company / issuer | Creates a private draft, uploads evidence, requests capital, receives released funds, and repays principal. | The verified wallet that owns the draft and is assigned as issuer. |
| Reviewer | Checks private evidence and approves the exact public Blueprint before funding opens. | One allowlisted reviewer wallet in the hackathon deployment. |
| Buyer | Confirms that the referenced purchase order belongs to the named transaction. | Only the buyer address assigned to that deal. No workspace or registration is required. |
| Capital provider | Reads an approved opportunity and contributes capital. | Any connected wallet; there is no funder application or allowlist in the prototype. |
Public opportunities are readable without a wallet. A connection is required only when identity or an onchain action matters. Dileo then requests a free message signature to create a resumable application session; that signature is not a transaction.
A single wallet is not permanently labeled “buyer” or “capital provider.” Permissions are evaluated per deal. A wallet may browse and fund generally, but only the address assigned as a particular deal’s buyer can confirm it.
The company or reviewer shares a focused /app/confirm/{deal} link after the Blueprint is approved. The buyer:
- opens the link without creating a company workspace;
- connects the wallet named on that deal;
- signs the free session message;
- reads the exact confirmation statement; and
- confirms the exact Blueprint commitment on X Layer.
Buyer confirmation recognizes the specified order. It is not a repayment guarantee, credit endorsement, or proof of legal authenticity.
Evidence review needs an accountable authority that is separate from the company asking for capital. Allowing every connected wallet to approve private evidence would make the approval meaningless.
The hackathon deployment therefore uses one allowlisted reviewer. The recommended production model is a policy-governed underwriting multisig: named operations and risk reviewers approve through threshold signatures, reviewer membership is recorded and revocable, decision policy is versioned, and custody remains separate. A production launch also requires legal onboarding, KYC/AML and sanctions controls, audit, monitoring, incident response, and jurisdiction-specific operating procedures.
| Stage | What the user does | What Dileo does | What becomes public |
|---|---|---|---|
| 1. Create | Company enters the parties, order, amount, and terms. | Saves a wallet-owned private draft that can be resumed. | Nothing. |
| 2. Supply evidence | Company uploads text-based supporting PDFs. | Keeps files private and extracts page-aware text. | Nothing. |
| 3. Analyze | Company starts Evidence Intelligence. | Produces attributable candidate facts, then independently rechecks money, dates, conflicts, and completeness. | Nothing. |
| 4. Review | Reviewer inspects sources and approves one exact Blueprint or requests changes. | Freezes the approved public representation and its evidence commitment. | Registration commitment when submitted onchain. |
| 5. Confirm | Named buyer opens the shared link and confirms. | Requires the assigned buyer wallet and exact Blueprint hash. | Buyer address, commitment, and confirmation transaction. |
| 6. Fund | Capital providers approve test dUSDC and contribute. | Holds contributions in an all-or-nothing escrow until the target is reached. | Wallets, amounts, timing, funding state, and events. |
| 7. Release | Reviewer releases a fully funded deal. | Transfers the funded principal to the issuer. | Release transaction and state. |
| 8. Repay or recover | Issuer repays principal; contributors claim. If cancelled, contributors claim refunds. | Uses pull-based claims so each contributor retrieves only their entitlement. | Repayment, refund, claim, or default events. |
| Route / view | Purpose | Wallet behavior |
|---|---|---|
/ |
Explains Dileo and its trust model. | No wallet required. |
/docs |
User-facing product, role, evidence, capital, and recovery guide. | No wallet required. |
/app?tab=explore |
Lists public opportunities. | Readable while disconnected. |
/app?tab=yours |
Separates the connected company’s active deals and resumable drafts. | Requires a verified wallet to show private ownership. |
/app/deals/{deal} |
Presents Overview, Blueprint, Evidence, Uncertainty, Intelligence, and Funding without one long review page. | Public summary is readable; private and role-bound actions remain protected. |
/app/create |
Creates or resumes a private deal through a focused workflow. | Requires a verified company wallet. |
/app/workspace |
Shows the independent reviewer’s queues. | Requires the allowlisted reviewer wallet. |
/app/confirm/{deal} |
Gives the named buyer one focused confirmation task. | Requires the exact buyer wallet for the transaction. |
Dileo uses AI for attributable extraction and cross-document reconciliation—not autonomous underwriting.
- PDFs are treated as untrusted data, never model instructions.
- The provider must return a versioned, strictly validated structured result.
- Every extracted fact names a source document, page, excerpt, and confidence.
- Dileo independently recalculates amounts, dates, totals, conflicts, and completeness.
- Results are tied to hashes and versions of the source documents.
- One repair attempt is allowed; failure publishes nothing and is shown honestly.
- The visible assistant answers only from the validated deal record and refuses unsupported questions.
- The Kora fallback is a persisted genuine provider result, clearly labeled when used.
The canonical Kora record reconciles a $100,000 order, $52,000 procurement, $8,000 logistics, and a $60,000 capital request while keeping missing cargo insurance visible.
| Contract | Address | Purpose |
|---|---|---|
| DemoUSDC | 0x1fc0…2774E |
Capped faucet token used only to rehearse funding. |
| DileoDealEscrow | 0x9e86…f3554 |
Exact Blueprint registration, buyer confirmation, funding, release, repayment, refund, and claims. |
Deployment transactions, blocks, compiler settings, and the reviewer address are recorded in contracts/deployments/xLayerTestnet.json. The originally supplied external token address had no bytecode on X Layer Testnet, so Dileo deployed a visibly test-only token instead of presenting an unusable address as live.
- A company can connect a wallet, create and resume private deal drafts, and add private PDF evidence.
- Dileo can extract source pages, run a real structured Groq analysis, and show an independently reconciled evidence record.
- A reviewer can inspect the private queue and approve the exact public Blueprint assigned to the deal.
- The named buyer can use a focused shared link to confirm that exact order.
- Any connected wallet can obtain test dUSDC and use the onchain funding actions allowed by the current deal state.
- Users can see pending, rejected, confirmed, repayment, refund, claim, and explorer states without a database state being presented as blockchain proof.
- Kora and all commercial documents are fictional.
- DemoUSDC has no monetary value.
- One reviewer wallet is allowlisted for the hackathon.
- Legal authenticity, credit decisions, KYC/AML, sanctions screening, production custody, and guaranteed repayment are outside this prototype.
- The contracts have automated tests but no independent audit.
- The deployed multi-wallet journey must still be completed by the configured reviewer and buyer wallets; the repository intentionally does not hold their private keys.
| Layer | Result | Coverage |
|---|---|---|
| Application | 12 passing tests | Money, lifecycle, completeness, Blueprint hashing, provenance, prompt injection, structured output, and repair behavior. |
| Production build | Pass | Next.js route compilation, static metadata, Docs, Privacy, Terms, app routes, and host proxy. |
| Contracts | 15 passing tests | Authority, exact Blueprint confirmation, lifecycle transitions, solvency, reentrancy, fee-on-transfer rejection, refund, repayment, and claims. |
| Live AI | Pass on 2026-08-21 | Real openai/gpt-oss-120b request—not a mock. Six Kora PDFs produced valid strict structured output on attempt one: 14 attributable facts, 4 risk observations, 8 reviewer questions, and a summary. |
| Deterministic reconciliation | Pass | Independent tests recompute money, dates, completeness, conflicts, provenance, Blueprint hashing, prompt-injection boundaries, and repair/failure behavior without trusting model conclusions. |
| X Layer deployment | Pass | Chain 1952, contract bytecode, configured roles, token metadata, balances, and explorer addresses verified. |
| Host routing | Local production pass | www serves marketing; app serves clean application and deal URLs; app-only paths do not leak onto www. |
| Testnet multi-wallet journey | Open | Requires the externally held reviewer and buyer wallets to sign the remaining transactions. |
Detailed evidence and honest open gates live in testing and release evidence.
Private PDFs → attributable AI extraction → deterministic evidence reconciliation
→ reviewer-approved Blueprint → buyer confirmation
→ X Layer escrow → funding / release / repayment / recovery
| Area | Responsibility |
|---|---|
app/ |
Public site, user guide, wallet application, private evidence, analysis, and chain interactions. |
contracts/ |
Test token, escrow, deployment scripts, generated bindings, and contract tests. |
fixtures/ |
Reproducible fictional Kora evidence. |
supabase/ |
Wallet-scoped persistence, row policies, and private evidence storage. |
shared/ |
The one deterministic Blueprint format used by both the app and contracts. |
docs/ |
Public judge, security, architecture, testing, and operations documentation. |
Marketing and application routes share one Next.js deployment. www.dileo.com serves the public site; app.dileo.com/* rewrites internally to /app/*.
Requirements: Node.js 22 LTS or Node.js 24, npm 10, and an X Layer-compatible browser wallet.
npm install
npm run fixtures:generate
npm run check
npm run devOpen http://localhost:3000/app. app.localhost:3000 exercises clean application-host routing.
Copy app/.env.example to app/.env.local and add server-only Supabase and Groq credentials. Add a WalletConnect Cloud project ID for QR/mobile-wallet support; injected wallets work locally. Never expose the Supabase service-role key, Groq key, or deployer private key through a NEXT_PUBLIC_* variable.
| Purpose | Command |
|---|---|
| Run the complete application and contract gate | npm run check |
| Rebuild the fictional Kora PDFs | npm run fixtures:generate |
| Compile contracts | npm run contracts:compile |
| Run contract tests | npm run contracts:test |
| Recheck the configured X Layer environment | npm --workspace @dileo/contracts exec hardhat run scripts/check-testnet-environment.ts --network xLayerTestnet |
| Deploy an X Layer Testnet contract set | npm run contracts:deploy:xlayer-testnet |
- Documentation index
- Judge demo guide
- Architecture and trust model
- Testing and release evidence
- Security and limitations
- Deployment and operations
The official AI Season page requires a Testnet deployment during the hackathon and a subsequent X Layer Mainnet launch. Its FAQ repeats that sequence rather than saying Mainnet must be completed before the submission deadline. Dileo therefore treats the verified Testnet deployment as the submission environment and Mainnet as the next launch milestone, with production controls completed before real-value activation. See the official AI Season requirements.
MIT