Agroasys is building a Commercial Trade Settlement Protocol on Polkadot Asset Hub: a non-custodial USDC escrow system that executes delivery-versus-payment (DvP) settlement for real-world trade using Ricardian contract anchoring (hashed PDF terms bound to a TradeID) and oracle-attested logistics milestones. We are requesting 94,000 USDC to complete the Web3 Layer implementation, ship an end-to-end testnet flow, and run a controlled pilot, while publishing the protocol components as reusable public infrastructure for any team needing conditional escrow settlement. We aim to be early practical testers of PolkaVM (RISC-V) for conditional business logic that becomes rigid or costly on typical EVM patterns.
Agroasys is an operational B2B trade coordination marketplace for commodity trade execution. We already run the off-chain coordination layer required to complete real trades, including:
What we have built so far
We have built the market and operations layer: verified counterparties, trade workflow coordination, and the execution processes needed to move physical goods. In parallel, we have already started implementing the Web3 Layer (core settlement protocol components are in active development in our public repository - agroasys.web3layer , and we are now seeking support to complete the remaining protocol scope, testing, and production hardening. The remaining bottleneck is settlement, which is why we are finishing the Web3 Layer as a reusable DvP settlement protocol.
Commodity trade execution still runs on two disconnected rails. The commercial rail is handled through documents and status updates (contracts, inspection reports, bills of lading, email threads), while the financial rail is handled through banks (SWIFT transfers and documentary instruments such as Letters of Credit). Because these rails do not share a common state machine, settlement and delivery coordination remain loosely coupled, slow to reconcile, and costly to operate at scale.
International commodity trade operates without a single shared state machine linking commercial events (shipment, inspection, document issuance) to financial settlement. This creates three persistent failure modes:
Delivery vs Payment trust gap
Sellers avoid shipping without payment certainty, and buyers avoid paying without shipment and quality certainty. The standard mitigation is bank intermediation such as Letters of Credit, which reduces counterparty risk but introduces cost, delay, and operational overhead (issuance and related charges are typically percentage-based and can reach several percent depending on structure and risk).
Settlement latency and operational drag
Even when terms are agreed, settlement is slow. Bank rails and compliance checks can delay payment by days, increasing working-capital pressure, extending cycle time, and raising the probability of disputes and reconciliation work across documents, counterparties, and banks.
Trade logic is conditional and document-driven
Commodity settlement is not a single transfer. Real agreements include conditional logic such as quality thresholds and penalties, partial releases, documentary gates (Bill of Lading, inspection certificates), exception handling (cancellation, expiry, dispute holds), and jurisdiction-aware resolution pathways. A Ricardian contract model is well suited here because it keeps the human-readable legal agreement as the source of truth while cryptographically binding it to execution triggers.
We are building a non-custodial settlement engine on Polkadot Asset Hub that binds a real-world trade agreement to on-chain USDC escrow and executes conditional releases based on verifiable trade events (document and milestone attestations). The protocol is designed as reusable infrastructure for any delivery-versus-payment flow that requires conditional escrow, documentary gates, and exception handling.
Core principles
Native USDC settlement on Asset Hub
For commercial settlement, bridged assets introduce an additional trust surface (bridge security model, liquidity fragmentation, operational failure modes). Polkadot Asset Hub supports native USDC, and the asset can be used across the ecosystem via XCM, which fits our requirement for stablecoin settlement without introducing bridge-specific risk. Implementation-wise, USDC is represented as a native asset on Asset Hub (for example, commonly referenced as asset ID 1337), which simplifies deterministic accounting and integration.
PolkaVM for conditional settlement logic
Trade settlement requires complex, conditional state transitions (partial releases, penalties, documentary gates, dispute holds, expiry paths). We intend to implement these flows using PolkaVM (RISC-V) to run richer business logic efficiently and to contribute early production feedback on tooling, performance, and operational reliability for RWA-style workloads. As part of delivery, we will publish benchmark and integration learnings as reusable reference patterns for other builders.
Step 1: Agreement anchoring (Ricardian binding)
Buyer and Seller execute a standard commercial agreement off-chain (PDF). The protocol computes a deterministic cryptographic hash of the signed document (TradeHash / TradeID). This TradeHash is committed on-chain and becomes the immutable anchor linking the legal agreement to the settlement state machine.
Step 2: Funding and escrow lock (non-custodial USDC)
The Buyer locks settlement funds by transferring USDC into the protocol’s escrow contract deployed on Polkadot Asset Hub. Agroasys does not custody funds at any point. Funds remain controlled by on-chain logic until release conditions are satisfied or an exception path is executed (expiry, cancellation, dispute hold).
Step 3: Trade event attestations (oracle + documentary references)
A Logistics Oracle submits signed attestations representing objective trade milestones, each linked to documentary evidence (for example, Bill of Lading reference, inspection certificate reference). Typical events include: ContractSigned, Shipped, InspectionPassed, Delivered. The oracle interface is schema-driven and designed for replay protection and idempotent processing.
Step 4: Conditional execution (PolkaVM state transitions)
Escrow release is governed by a contract state machine that evaluates the current trade state against the pre-agreed conditions bound to the TradeHash. Execution supports conditional outcomes such as partial releases, penalty deductions, holds, and dispute/exception routing based on milestone attestations.
Step 5: Settlement finality (USDC payout)
When release conditions are satisfied, the escrow contract transfers USDC to the Seller (and routes protocol fees if applicable). Settlement is finalized on-chain with auditable events that can be indexed for reconciliation, reporting, and dispute review.
A major blocker to adoption is requiring counterparties to adopt new wallet tooling and operational processes before they see measurable value. Our onboarding strategy is to keep the settlement experience familiar while preserving non-custodial guarantees and full auditability.
Approach: abstraction + enterprise-friendly UX
To match the scope required to ship a usable, secure settlement protocol (on-chain escrow, oracle interface, minimal orchestration services, and production hardening), we will deliver the work in two phases under one treasury proposal. The phases are sequencing and delivery structure, not separate funding requests.
Phase 1 covers Milestones 0–2 (76,000 USDC). This phase delivers the protocol foundation and the core settlement engine: specification and threat model, escrow and fee routing on Asset Hub, and the minimum orchestration services required to run an end-to-end testnet settlement flow.
Phase 2 covers Milestones 3–5 (18,000 USDC). This phase focuses on shipping what is required to operationalize the protocol safely and make it reusable: indexing and reconciliation essentials, minimal product integration components needed for the pilot, and targeted security hardening and production readiness items.
Note: KYC/KYB/KYT/AML internal engines are excluded (handled by third-party providers). We only build the integration hooks and operational workflows needed for the settlement layer to function safely.
Timeline: Weeks 1–2
Cost: 8,000 USDC
Goal: Lock scope, interfaces, and security boundaries to prevent rebuilds and ensure correctness of the settlement lifecycle.
| Task | Deliverable | Cost (USDC) | Notes |
|---|---|---|---|
| 0.1 Protocol & State Machine Spec | Versioned protocol spec | 3,000 | Trade lifecycle, roles (Buyer/Supplier/Admin), state transitions, timeout/dispute rules. |
| 0.2 Contract Interface Spec | Contract ABI + events/errors | 2,000 | Defines calls/events for escrow, oracle gating, fees, cancellations, holds. |
| 0.3 Oracle Spec & Attestation Format | Oracle message schema + signing rules | 1,500 | Signature format, replay protection, idempotency rules, key rotation approach. |
| 0.4 Threat Model & Security Checklist | Threat model + mitigation checklist | 1,500 | Top risks across contract/oracle/UI/infra + test plan for critical paths. |
Timeline: Weeks 3–8
Cost: 44,000 USDC
Goal: Build the on-chain settlement engine on Asset Hub (USDC escrow, conditional release, and fee routing), with deterministic builds and rigorous testing.
| Task | Deliverable | Cost (USDC) | Notes |
|---|---|---|---|
| 1.1 Escrow Smart Contract Core | Escrow contract repo + docs | 18,000 | createTrade, deposit, release, cancel, pause, disputeHold, expiry handling. |
| 1.2 Fee Splitting & Treasury Routing | Fee routing logic + treasury payout | 6,000 | Supplier receives principal; platform/logistics fees routed to treasury wallets. |
| 1.3 Oracle-Gated State Transitions | Oracle-gated actions | 6,000 | "Shipped/Inspected/Delivered" gating, authorization checks, replay-safe design. |
| 1.4 Deterministic Builds | Reproducible build pipeline (Docker) | 6,000 | Verifiable builds: source ↔ deployed artifact integrity. |
| 1.5 Testing (Unit + Invariant) | Test suite + CI checks | 8,000 | State machine invariants, edge cases, failure paths, fuzz/invariant-style coverage. |
Acceptance Criteria: End-to-end testnet flow: create trade → deposit USDC → oracle confirm → supplier payout + treasury payout; plus cancel/timeout/disputeHold paths verified.
Timeline: Weeks 9–14
Cost: 24,000 USDC
Goal: Build the off-chain services that make the protocol usable: contract hashing, storage, oracle relay, APIs, notifications, and user/org auth.
| Task | Deliverable | Cost (USDC) | Notes |
|---|---|---|---|
| 2.1 Auth Service + User/Org Profiles | Auth service + role system | 5,000 | Buyer/Supplier/Admin roles; org profiles; integration hooks for 3rd-party compliance. |
| 2.2 Primary DB (Postgres) + Audit Logs | Schema + migrations + audit logging | 4,000 | Trade records, document metadata, action logs, operator events. |
| 2.3 Ricardian Service (PDF Hashing) | Hash API + verification endpoints | 6,000 | Generates TradeHash (SHA-256), validates hashes, ties contract → trade lifecycle. |
| 2.4 Ricardian Storage | Storage layer + access controls | 3,000 | Secure storage for contract PDFs + metadata, retention policy. |
| 2.5 Oracle Service (Logistics Data Relay) | Oracle node/service repo | 4,000 | Signed attestations, replay protection, idempotent submits, on-chain posting flow. |
| 2.6 Notifications Service | Notification triggers + templates | 2,000 | Status updates (email/WhatsApp/SMS optional), operator alerts for critical events. |
Acceptance Criteria: Trade created via API results in: TradeHash stored + on-chain trade created + indexed state available + oracle update triggers correct contract transition.
Timeline: Weeks 15–22
Cost: 7,000 USDC
Goal: Make the system reliable: indexing, GraphQL/API, reconciliation, error handling, monitoring, and CI/CD.
| Task | Deliverable | Cost (USDC) | Notes |
|---|---|---|---|
| 3.1 Indexer Service | Indexer repo + deployment | 2,500 | Tracks escrow events, balances, oracle events, fee routing, dispute states. |
| 3.2 GraphQL API | GraphQL schema + resolvers | 2,000 | Trade timeline, status, balances, documents, actions allowed, audit visibility. |
| 3.3 Reconciliation Engine | Reconciliation reports + alerts | 1,500 | On-chain truth vs DB state, stuck-state detection, operator remediation workflows. |
| 3.4 Error Handler / Retry System | Retry + dead-letter workflows | 500 | Idempotent processing, failure isolation, operator alerting. |
| 3.5 Infra + Monitoring + CI/CD | Monitoring dashboards + pipelines | 500 | Observability, alerts, deployments, secrets management, runbooks. |
Acceptance Criteria: On-chain events reflected in API within a defined SLA; reconciliation detects mismatches; monitoring alerts on forced failures.
Timeline: Weeks 23–32
Cost: 7,000 USDC
Goal: Ship the complete user flow: login, create trade, deposit, track milestones, settle; then run a real pilot transaction.
| Task | Deliverable | Cost (USDC) | Notes |
|---|---|---|---|
| 4.1 Agroasys Dashboard | Production dashboard (React/TS) | 3,000 | Trade creation, role-based actions, status timeline, document views, admin controls. |
| 4.2 Wallet Integration | Wallet login + abstraction | 2,000 | Integrate 3rd-party non-custodial wallet provider for seamless onboarding and user key control. |
| 4.3 Fiat Ramp Widget | Embedded ramp + callbacks | 1,000 | Funding via partner widget; fallback to manual USDC deposit. |
| 4.4 Pilot Execution | Pilot + tx hashes + report | 1,000 | Execute live settlement (>$10k USDC) + timeline/cost report + ops guide. |
Acceptance Criteria: Non-crypto user can: login → create trade → fund → observe oracle updates → settlement completes; pilot evidenced by tx hashes and report.
Timeline: Weeks 33–38
Cost: 4,000 USDC
Goal: Reduce protocol risk before scaling volume: security review, abuse testing, and production readiness documentation.
| Task | Deliverable | Cost (USDC) | Notes |
|---|---|---|---|
| 5.1 SC Security Review | Review/audit report + fixes | 2,500 | Professional security review; resolve critical/high issues. |
| 5.2 Oracle & Key Mgmt | Oracle security report + fixes | 500 | Key rotation, replay protection validation, access controls, rate limits. |
| 5.3 Abuse & Resilience | Stress tests + incident drills | 500 | Failure modes: oracle down, indexer lag, DB outage, replay attempts. |
| 5.4 Production Pack | Runbooks + deployment docs | 500 | Ops handbook, incident response checklist, monitoring baselines, rollback strategy. |
Acceptance Criteria: Security findings addressed; readiness checklist completed; system can be operated continuously with monitoring and documented incident procedures.
| Phase | Milestones | Total (USDC) |
|---|---|---|
| Phase 1 | Milestones 0–2 | 76,000 |
| Phase 2 | Milestones 3–5 | 18,000 |
| Grand Total | Milestones 0–5 | 94,000 |
| Risk Area | The Reality | Mitigation |
|---|---|---|
| Adoption risk | Enterprises resist changing settlement behavior; “USDC” is often perceived as “crypto risk.” | Lead with operational outcomes (faster settlement, fewer disputes, clearer audit trail) and demonstrate the workflow with small pilots. Keep the UX familiar and USD-denominated, with clear states and human-readable documents tied to each step. |
| Technical risk (PolkaVM is new) | New execution environments can have tooling gaps, runtime edge cases, and unknown performance characteristics. | Use phased delivery, deterministic builds, and comprehensive testing (unit, invariant, fuzz). Keep contract logic modular and spec-driven. Start with limited-scope pilots and increase complexity only after reliability is proven. |
| Oracle trust risk | Oracles can become the weakest link if attestations are ambiguous or too powerful. | Restrict oracle authority to signed, schema-validated attestations that only unlock pre-defined transitions. Add replay protection, idempotency, key rotation, and evidence references. Design for future multi-source attestations while keeping the pilot deployable. |
| Regulatory / compliance risk | “Are you a money transmitter?” is a legitimate question in many jurisdictions. | Maintain a non-custodial structure (wallet → escrow contract → wallet). Agroasys provides software and orchestration, not custody. Keep an auditable trail of user approvals and contract-bound conditions, and rely on third-party compliance providers where required. |
| Operational / document fraud risk | Fake documents, mismatched shipments, and quality manipulation exist in real trade flows. | Bind each trade to a Ricardian contract hash and require oracle updates to reference verifiable documents (inspection reports, BoL identifiers) with strict schema validation. Provide dispute and exception pathways (holds, timeouts, cancellations) that map to the agreed contract terms. |
| User key management risk | Lost keys or poor recovery UX can block access to funds and harm adoption. | Support non-custodial wallet integration that offers recovery-friendly UX without taking custody. Make approvals explicit, provide clear account recovery flows where supported by the wallet provider, and maintain transparent guidance for enterprises using native wallets. |
| Stablecoin / rails risk | Stablecoin access and off-chain funding rails vary by region, counterparties, and settlement corridors. | Start with corridors and counterparties where USDC settlement is already practical. Provide multiple funding options (direct stablecoin transfer and optional ramp integrations) and expand coverage incrementally as rails and counterparties mature. |
This work targets Asset Hub as a practical settlement venue for real-economy flows. If successful, it brings repeatable USDC escrow and release activity driven by commercial events, not speculative trading, which translates into consistent fee-generating transactions and observable on-chain utility.
We will publish a reference implementation for delivery-versus-payment settlement that is legally anchored. Core patterns such as escrow state machines, Ricardian contract hashing and verification, oracle attestation formats, and dispute/exception pathways will be open-sourced where possible so other teams can reuse them for adjacent RWA workflows.
PolkaVM requires production-like workloads to mature. This protocol is intentionally “messy” in the way real trade is messy: partial releases, penalties, timeouts, cancellations, and evidence-driven state transitions. We will publish learnings on performance, edge cases, deterministic build practices, and testing strategies so future PolkaVM teams can build faster and safer.
We are requesting support beyond funding. We want technical alignment and review so the protocol matches Polkadot expectations and can be reused by other builders.
We request feedback on the standards and conventions the ecosystem prefers for RWA settlement, including data schemas, event and error design, oracle message formats, and audit conventions. We also request guidance on document-backed oracle architectures that minimize trust while remaining deployable in real operations.
Finally, we request PolkaVM early adopter guidance, including tooling expectations, deterministic build best practices, recommended testing approaches, and integration patterns the ecosystem would like this project to validate and document.
This protocol is built around capabilities that are specifically strong on Polkadot Asset Hub: native USDC settlement and system-level interoperability via XCM. For an institutional settlement workflow, using native assets on a system chain is materially different from relying on bridged liquidity and external trust assumptions.
PolkaVM enables the implementation style required for complex conditional settlement. The target workload is not “send funds,” but commercial settlement with a state machine that includes escrow holds, partial releases, penalties, expiry, cancellations, and dispute holds bound to a Ricardian contract hash and oracle attestations.
Agroasys is already executing trade coordination off-chain and is converting that operational logic into a reusable settlement primitive. If RWA on Polkadot is intended to mean real delivery-linked settlement on-chain, this protocol is designed to be that shape: non-custodial escrow, legally anchored terms, and evidence-driven release conditions.
Discussion is now open. Please we would love your reviews on this and thank you very much