> For the complete documentation index, see [llms.txt](https://ga.orilife.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ga.orilife.io/qna/accountability.md).
# Accountability
Q: What specifically are the \~100 on-chain events per hectare per year?
The 100 events/ha/year is a planning estimate reflecting expected average farming activity:
* \~50 VeData batch anchors — cultivation logs, Bio-ID updates, harvest events (\~weekly during growing season)
* \~25 labor contract engagements — 2 permanent workers × 12 monthly payments + 1–2 harvest khoán contracts per year (Source: CropTex; QĐ 3763/QĐ-UBND Đắk Lắk 19/12/2019)
* \~5 commercial escrow transactions — advance deposit + final settlement per harvest batch
* \~8 one-time setup events — DID registration, Farm NFT minting, harvest module activation
Path B audit decommits (\~2,190/year) are a fixed system cost that does not scale per hectare and is excluded from this formula. Active farms during peak harvest months will generate more; smaller or less active farms will generate fewer. The \~1,200,000 total is the upper bound planning estimate.
***
Q: Is "25 labor contracts/ha/year" based on actual Đắk Lắk employment data?
Yes, derived from official field data. From QĐ 3763/QĐ-UBND Đắk Lắk (19/12/2019) and CropTex field research: 1 ha durian requires 2 permanent workers year-round at 5–7M VND/person/month. 2 workers × 12 monthly payments = 24 labor payment engagements/year, plus 1–2 harvest khoán contracts per harvest season. Total: \~25–26 individual labor engagements/year. The GA uses 25 as a conservative lower bound.
***
Q: Is "5 commercial escrow tx/ha/year" consistent with actual durian trade structure?
Yes. Đắk Lắk durian trade typically involves: 1–2 advance deposits from traders before harvest + 1–2 final settlements after delivery + occasional partial payments in multi-batch sales. \~3–5 commercial transactions/ha/year is the realistic estimate. The GA uses \~5 as the planning upper bound. (Source: DDC Holdings field experience across 46 communes; confirmed by trade structure analysis from the 2025 scandal investigation)
***
Q: Under a realistic downward scenario (\~700,000 events/year), are milestones still achievable?
Yes. M7 requires ≥100,000 on-chain transactions during the M7 period (1–2 months). At 700,000 events/year, 2 months = \~117,000 transactions — M7 passes comfortably. The 700,000 scenario is likely the Year 1 reality as the ecosystem builds up, not a failure scenario. It becomes the baseline from which organic growth occurs as more enterprises integrate the SDK.
***
Q: How does the design prevent gaming M7's "≥100,000 on-chain tx" acceptance criterion?
Four independent layers: (1) Each transaction costs real MAGIC credits paid by users — generating empty transactions is economically self-defeating. (2) 5-layer VeData validation rejects invalid data before it reaches Cardano; fake records cannot pass biological plausibility checks. (3) IOB Member 3 independently verifies field evidence — GPS photos, district reports, and dashboard data must corroborate on-chain activity. (4) Random 5% spot checks require field inspectors to confirm that on-chain records correspond to physical farms and trees.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://ga.orilife.io/qna/accountability.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.