Agroasys

[Astonstevn]

Project Abstract

Agroasys is a Web3-enabled agricultural trade settlement platform that makes cross-border agri-trade legally enforceable, transparent, and tamper-evident. It combines Ricardian Contracts (human-readable, cryptographically signed, and court-enforceable agreements) with Polkadot AssetHub primitives for on-chain anchoring, contract verification, and USDC-based settlements. The system solves longstanding challenges in agri-trade such as fraud, counterparty risk, opaque workflows, and slow settlements by providing deterministic settlement logic, multi-party signing flows, and verifiable on-chain proofs that integrate seamlessly with existing enterprise processes.

Our architecture uses off-chain services for contract generation, identity verification, custodial wallet management, and settlement orchestration, while leveraging AssetHub’s system.remark and Assets pallet for secure, production-grade blockchain interactions. Agroasys delivers a scalable and enterprise-ready infrastructure that exporters, aggregators, and international buyers can rely on for transparent, digitally enforceable agricultural trade. By bridging real-world legal enforceability with Web3 verification and settlement rails, Agroasys aims to become the foundational trust and settlement layer for agricultural export economy.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[Astonstevn]

I have read and hereby sign the Contributor License Agreement.

[Astonstevn]

@keeganquigley requesting your review

[Astonstevn]

@keeganquigley Requesting your review

[keeganquigley]

Hi @Astonstevn apologies for the delay while we waiting for some things to be clarified internally. One question I would have is about the KYC/KYB verification and custodial wallet management. Why not make it completely non-custodial? Since relying on KMS/HSM opens possible attack vectors, for example blind signing. Will your KMS policy enforce restrictions on the content of what is being signed, or does it just sign any hash provided by the backend?

[Astonstevn]

Thanks @keeganquigley,
So we are building a B2B marketplace that requires KYC/KYB for compliance. The reason we are using a custodial wallet system (with KMS/HSM) is because:

1. User Experience and Recovery: B2B users (enterprises) may not be familiar with managing private keys. A custodial system allows for key recovery, which is critical for business continuity.
2. Compliance and Security: We need to enforce KYC/KYB checks and monitor transactions for AML/CFT. A custodial system allows us to integrate these checks before signing any transaction.
3. Multi-party and Escrow: Our platform requires complex settlement logic, escrow, and dispute resolution. Having control over the signing process allows us to implement these features.

Regarding the security of the KMS/HSM and blind signing:

1. Our KMS/HSM policy will enforce restrictions on what is being signed. We are not using a simple key store that signs any hash. Instead, we have a transaction signer service that constructs the transaction and then sends it to the KMS/HSM for signing. The KMS/HSM is configured with policies that validate the transaction structure and context.
2. We are implementing transaction simulation and review for critical operations (like large transfers) to prevent blind signing. The backend will provide the transaction details (including recipient, amount, and contract call data) to the KMS/HSM, which will only sign if the transaction matches allowed patterns.
3. Additionally, we have a multi-layer approval process for high-value transactions, which may require multiple keys (multi-signature) or manual approval from the platform's security team.
4. We are also considering hardware security modules (HSMs) that support advanced features like transaction parsing and validation, so the HSM itself can reject malicious transactions.

So in short, we are aware of the risks of blind signing and are designing our KMS/HSM policies to mitigate these risks by validating the transaction content and context. We are also implementing additional security measures such as multi-signature and transaction simulation.