1) What this is, in one paragraph

Agroasys is building Cotsel (Commercial Trade Settlement Layer) on Polkadot Asset Hub: a non-custodial stablecoin escrow and settlement state machine for cross-border trade workflows. Cotsel links the commercial agreement to settlement execution through Ricardian anchoring (a SHA-256 hash of the signed PDF recorded as a TradeID) and advances settlement through oracle-attested milestones tied to documentary evidence (for example shipment and inspection references). We are requesting 94,000 USDC to complete the remaining implementation, deliver an end-to-end testnet flow with deterministic build evidence and operational runbooks, and execute a controlled pilot. The core components will be published as reusable infrastructure for teams that need evidence-driven, milestone-gated settlement. Where applicable, we intend to align with the PolkaVM (RISC-V) toolchain to validate conditional business logic execution paths beyond typical EVM constraints.

---

2) Origin and execution context

Cotsel originated from work on the Agroasys trade execution platform, where we saw a recurring structural issue in real trade operations: the commercial state of a deal moves forward through documents and milestones (contract signing, shipment, Bills of Lading, inspection outcomes), while the financial state remains gated by slow and opaque settlement rails. After evaluating existing approaches and researching what would be required for production-grade delivery-versus-payment in commodity workflows, we concluded that the missing piece is a non-custodial settlement layer that can bind an agreement reference to a deterministic state machine and advance settlement only on verifiable, document-backed events.

Cotsel is therefore designed around operational reality, not idealized assumptions. It treats documentary completeness and inspection outcomes as first-class settlement inputs, supports explicit exception paths such as timeouts, cancellations, and dispute holds, and produces an auditable execution trail suitable for reconciliation and dispute review. Although the initial intent came from the Agroasys context, Cotsel is published as reusable infrastructure so that any trade workflow, marketplace, or operator can adopt the same evidence-driven escrow pattern and deterministic settlement lifecycle.

What we have built so far

The market and operations layer is live. It includes verified counterparties, repeatable trade workflows, and operational processes that move physical goods and produce the evidence required for acceptance and dispute review. In parallel, we have started implementing the settlement layer, Cotsel, and core protocol components are in active development in our public repository (Cotsel). The remaining bottleneck is settlement determinism: today, the commercial state and the financial state do not converge in a single state machine, which drives coordination overhead and increases dispute and working-capital risk. We are seeking support to complete the remaining protocol scope, testing, and production hardening required to run a controlled pilot and publish Cotsel as reusable DvP settlement infrastructure.

---

3) Context: Trade execution is digitizing, but settlement remains bank-bound

Commodity trade execution still operates across two independent rails. The commercial rail is managed through document-driven workflows and informal status propagation, including contracts, inspection outputs, Bills of Lading, and email-based handoffs. The financial rail is managed through bank settlement and documentary risk instruments, including SWIFT transfers and Letters of Credit. Because these rails do not converge on a shared state model, delivery and settlement remain loosely coupled. This creates latency in release decisions, increases manual reconciliation, and drives higher operating cost when trades scale across corridors, counterparties, and compliance regimes.

Commercial rail: PDFs, email threads, scanned documents, and manual status updates

Financial rail: bank settlement (SWIFT latency) and documentary instruments (LCs) used to mitigate counterparty risk

---

4) Problem: The Synchronization Gap (no shared state between delivery and payment)

International commodity trade lacks a shared state machine that binds commercial events to financial settlement. Shipment progression, inspection outcomes, and documentary issuance live in one operational reality, while payment finality and risk mitigation live in another. Because these systems do not converge on a single, auditable lifecycle, delivery and payment coordination is executed through manual coupling, producing recurring failure modes that do not disappear with scale.

The first failure mode is delivery versus payment misalignment. Sellers avoid releasing goods without payment certainty, and buyers avoid paying without shipment and quality certainty. The prevailing mitigation is bank intermediation through documentary instruments such as Letters of Credit, which can reduce counterparty risk but introduces cost, delay, and operational overhead in issuance, amendments, and document checking.

The second failure mode is settlement latency and reconciliation drag. Even when terms are agreed, bank settlement and compliance processes introduce multi-day delays. During this gap, goods and documents advance while payment remains pending, increasing working capital pressure and extending cycle time. When exceptions occur, such as document discrepancies, quality claims, or timeline slippage, reconciliation expands across parties and artifacts because the payment rail is not natively linked to the commercial evidence trail.

The third failure mode is that real trade settlement is conditional and evidence-driven, not a single transfer. Commercial agreements often require partial releases, documentary gates such as Bills of Lading and inspection certificates, penalty logic based on measurable thresholds, and explicit exception paths including cancellation, expiry, and dispute holds. A Ricardian contract model fits this operating reality by keeping the human-readable agreement as the source of truth while anchoring a cryptographic reference that can be used to bind evidence and settlement state to the same lifecycle.

---

5) Solution: Cotsel (non-custodial settlement on Asset Hub)

Cotsel is a non-custodial settlement layer built on Polkadot Asset Hub. It binds a signed commercial agreement to on-chain USDC escrow and advances settlement through conditional, milestone-gated state transitions driven by verifiable trade events. These events are represented as document-backed attestations, for example shipment evidence and inspection outcomes, and are applied deterministically by the settlement state machine. Cotsel is designed as reusable infrastructure for delivery-versus-payment workflows that require conditional escrow, documentary gates, and explicit exception handling.

The system is non-custodial by design. Funds move from a user-controlled wallet into an escrow contract and are released only according to the contract state machine. No off-chain operator, including Agroasys, can arbitrarily move user funds outside the defined transition rules and authorization boundaries.

The agreement is treated as the source of truth. Cotsel uses Ricardian anchoring to hash the signed legal document into a TradeID recorded on-chain as an immutable reference. Settlement state, evidence references, and release conditions are linked to this TradeID so that execution remains traceable to a specific agreement artifact.

Settlement is stablecoin-denominated. Cotsel targets native USDC on Asset Hub to avoid volatility as a business constraint and to keep pricing, accounting, and reconciliation in USD terms. This supports enterprise adoption by reducing treasury complexity and minimizing the need for counterparties to manage exposure to volatile assets.

---

6) Why Polkadot (and why Asset Hub specifically)

Native USDC settlement on Asset Hub

Polkadot Asset Hub provides a stable settlement rail with native USDC issuance, which reduces additional trust surfaces introduced by bridged assets, such as bridge security assumptions, liquidity fragmentation, and corridor-specific operational failure modes. Circle confirms that USDC is natively issued on Polkadot Asset Hub and can be transferred across the ecosystem via XCM, which matches the requirement for stablecoin settlement without introducing bridge-specific risk.  Asset Hub also represents USDC as an on-chain asset with a consistent identifier, commonly referenced as asset ID 1337, which supports deterministic accounting and integration. 

Trade settlement requires conditional state transitions that reflect real commercial logic, including partial releases, documentary gates, penalties, dispute holds, and expiry paths. We intend to implement and validate these flows against the PolkaVM (RISC-V) direction to support richer business logic execution and to contribute early feedback on tooling, performance, and operational reliability for RWA-style workloads. Polkadot’s own smart contracts documentation frames PolkaVM as the RISC-V execution path alongside EVM compatibility, and the wider ecosystem has positioned PolkaVM specifically to enable more efficient execution of complex contract logic.  As part of delivery, we will publish benchmark and integration learnings, including tradeoffs, toolchain patterns, and operational runbooks, as reusable reference material for other 

---

7) System Design (end-to-end settlement flow)

Cotsel implements a deterministic settlement lifecycle that binds an off-chain commercial agreement to an on-chain escrow state machine and advances settlement through evidence-linked milestone attestations. The intent is to converge the commercial state and the financial state into a single, auditable execution path, with explicit exception handling and operational traceability.

Agreement anchoring (Ricardian binding)

Buyer and seller execute a standard commercial agreement off-chain. The signed agreement is hashed deterministically to produce a TradeID. The TradeID is committed on-chain and serves as the immutable anchor linking the legal agreement artifact to the settlement lifecycle. All subsequent evidence references, milestone attestations, and settlement transitions are associated with this TradeID to keep the execution path traceable to a single agreement reference.

Funding and escrow lock (non-custodial USDC)

The buyer funds settlement by transferring USDC into the escrow contract. Funds are never custodied by Agroasys or any off-chain operator. Once locked, funds are controlled only by the contract state machine until release conditions are satisfied or an explicit exception pathway is executed, including cancellation, expiry, or dispute hold.

Trade event attestations (oracle with documentary references)

Settlement progression is driven by signed milestone attestations submitted by an oracle service. Each attestation represents an objective trade event and carries references to documentary evidence, such as Bills of Lading and inspection certificate identifiers. The oracle interface is schema-driven, authorization-scoped, and designed for replay protection and idempotent processing so that repeated submissions do not create inconsistent state.

Conditional execution (state transitions)

The escrow contract evaluates the current trade state against the pre-agreed conditions associated with the TradeID. State transitions support real commercial outcomes, including partial releases, fee routing, penalty deductions, holds, and dispute routing. This ensures that settlement is not a single transfer, but a controlled execution flow aligned with documentary gates and measurable acceptance criteria.

Settlement finality (USDC payout and auditability)

When release conditions are satisfied, the escrow contract transfers USDC to the seller and routes any configured fees to their recipients. The system emits auditable events for each state transition and payout, enabling indexing for reconciliation, operational reporting, and dispute review.

---

8)  Onboarding Strategy (bringing enterprises and users on-chain without changing their workflows)

Adoption fails when counterparties are forced to change tools and behavior before they experience measurable value. Cotsel is designed so that the settlement workflow remains familiar, while custody risk and settlement uncertainty are reduced through non-custodial escrow and auditable state transitions. The onboarding goal is to abstract blockchain complexity without weakening security guarantees or traceability.

The user-facing experience is intentionally USD-native. Counterparties interact with USD-denominated values, explicit lifecycle states, and a minimal set of approvals aligned to trade milestones. Common states such as Funds Locked, Shipped Verified, and Released map directly to operational expectations and reduce the cognitive load associated with blockchain primitives. Behind the scenes, the system produces traceable receipts and on-chain references that can be used for reconciliation and dispute review, but these are surfaced as evidence links rather than as “crypto” concepts.

Authentication and wallet onboarding follow enterprise-friendly patterns. Users should be able to authenticate using familiar login methods, including email-based flows and SSO-style patterns, through a third-party non-custodial wallet integration. The design intent is that a wallet is provisioned for the user while the user retains control of keys and funds. The protocol never holds private keys and cannot move funds outside the escrow rules and contract state machine.

Funding paths must be practical and corridor-aware. In early deployments, escrow funding can be supported through direct stablecoin transfer and structured funding flows based on what is operationally feasible for each counterparty. The system should support fallbacks and clear failure states, so funding can complete even when a preferred method is unavailable.

The operational objective is straightforward. The settlement layer should feel like a standard trade workflow with stronger guarantees. On-chain complexity is minimized and is primarily visible only as verifiable events, receipts, and settlement finality when needed for operational assurance.

---

9) Milestones and Budget (Total: 94,000 USDC)

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.

---

Project Roadmap: Phases 1 & 2

---

Phase 1 — Milestones 0–2: Foundation + Core Settlement + Orchestration

---

Milestone 0 — System Spec, Threat Model, and Execution Plan

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.

---

Milestone 1 — Asset Hub Settlement Core (Escrow + Fees + Treasury Routing)

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.

Acceptance Criteria: End-to-end testnet flow: create trade → deposit USDC → oracle confirm → supplier payout + treasury payout; plus cancel/timeout/disputeHold paths verified.

---

Milestone 2 — Platform Orchestration Services

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.

Acceptance Criteria: Trade created via API results in: TradeHash stored + on-chain trade created + indexed state available + oracle update triggers correct contract transition.

---

Phase 2 — Milestones 3–5: Indexing/Infra + Product Integration + Security Hardening

---

Milestone 3 — Data Sync, Indexing, Reconciliation, Error Handling, and Infra

Timeline: Weeks 15–22
Cost: 7,000 USDC
Goal: Make the system reliable: indexing, GraphQL/API, reconciliation, error handling, monitoring, and CI/CD.

Acceptance Criteria: On-chain events reflected in API within a defined SLA; reconciliation detects mismatches; monitoring alerts on forced failures.

---

Milestone 4 — Frontend + Wallet Integration + Fiat Ramp + Operational Pilot

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.

Acceptance Criteria: Non-crypto user can: login → create trade → fund → observe oracle updates → settlement completes; pilot evidenced by tx hashes and report.

---

Milestone 5 — Security Review, Hardening, and Production Readiness

Timeline: Weeks 33–38
Cost: 4,000 USDC
Goal: Reduce protocol risk before scaling volume: security review, abuse testing, and production readiness documentation.

Acceptance Criteria: Security findings addressed; readiness checklist completed; system can be operated continuously with monitoring and documented incident procedures.

---

Budget Summary

---

10) Realistic Risks & Mitigation

---

11) Impact on Polkadot

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.

12) What We Need From the Community

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.

13) Why this is Polkadot-native

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