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, court-enforceable agreements) with Polkadot AssetHub Smart Contracts for on-chain logic, fund locking, and automated USDC-based settlements. The system solves longstanding challenges in agri-trade such as fraud, counterparty risk, and slow settlements by providing deterministic smart contract logic and verifiable Non-Custodial Multi-Party Computation (MPC) signing flows that integrate seamlessly with existing enterprise processes.

Our architecture uses off-chain services for contract generation, identity verification, and Oracle-based logistics validation, while leveraging PolkaVM for secure, programmable blockchain interactions. Agroasys delivers a scalable and enterprise-ready infrastructure where exporters, aggregators, and international buyers transact using "Invisible Wallets" (MPC), retaining full control of their keys while benefiting from the platform's seamless UX. By bridging real-world legal enforceability with Web3 settlement rails, Agroasys aims to become the foundational trust layer for the 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.

[keeganquigley]

Thanks for your answers @Astonstevn I will mark the application as ready for review and ping the committee for comment.

[Astonstevn]

Thanks @keeganquigley

[Astonstevn]

Hi @keeganquigley,

I hope you're having a wonderfull holidays. After a deep architectural review with our engineering team, we have concluded that we are pivoting away from the custodial KMS model entirely. We realized that holding user keys creates unnecessary liability and introduces "blind signing" risks that are difficult to fully mitigate, even with strict policies.

Crucially, we also identified a major regulatory blocker: Acting as a custodian for B2B funds would likely classify us as a Money Transmitter or VASP (Virtual Asset Service Provider) in multiple jurisdictions. This would impose heavy licensing requirements that are outside the scope of a technology startup.

We have updated our entire architecture to be fully Non-Custodial to solve both the Security and Regulatory challenges:

1. Identity & Signing (MPC): We are now implementing Web3Auth (MPC). This allows our enterprise users to log in via standard SSO (Google/Email) and generates a non-custodial wallet in the background. The key is sharded and reconstructed only in the user's client environment. We never see or hold the user's private key.
2. Smart Contract Settlement: We are moving from simple asset transfers to Escrow Smart Contracts on PolkaVM (AssetHub). Instead of us "admin-signing" a transfer, the user directly signs a createTrade transaction that locks funds and stores the Ricardian Contract hash on-chain.
3. The "Oracle" Role: Our platform now acts strictly as a Verification Oracle. We verify off-chain logistics data (DHL/Maersk) and provide a cryptographic signature that the Smart Contract requires to release funds. We "call the shot" based on verified data, but we cannot move the funds arbitrarily.

This shift significantly improves security, removes the central point of failure, and keeps our legal status clear while maintaining the frictionless UX our enterprise clients need.

I have updated the proposal (Abstract, Roadmap, and Milestones) to reflect this new Non-Custodial + Smart Contract architecture. We are ready to proceed.

[Astonstevn]

Hi @keeganquigley any updates?

[keeganquigley]

Hi @Astonstevn sorry for the delay here. Unfortunately, the proposal was unable to garner enough approvals from the committee to be accepted. Additionally, the W3F is shutting down the grants program, meaning we won't accept a revised proposal. Very sorry to be the bearer of bad news here and thanks so much for your cooperation thus far in the process. Will let you know if this changes in the future.

[Astonstevn]

Thanks @keeganquigley