Updated Proposal – v2 (Supersedes v1)
We’ve taken the time to update the proposal, incorporating as much detail as possible from all the questions raised and addressing them in their respective sections. We believe the proposal is now clearer, more robust, and an overall stronger read.
Changes since v1:
- Reduced grant size
- Updated sections to include the information in the replies from queries
- Updated delivery milestones
We would kindly ask reviewers to focus feedback on the new version.
[2512] MORA Trace Ledger – Blockchain-Anchored Transparency for Food and Drink Products v2
1 Project Name & Description
MORA Trace Ledger – Blockchain-Anchored Transparency for Food and Drink Products v2
This project delivers a lightweight, web-based food traceability MVP built on the Rootstock ecosystem, demonstrating how Bitcoin-secured infrastructure can be adopted by our target users: MSME (Micro, Small, and Medium Enterprises), Artisans, small Farmers, and Producers. Batch-level production and certification data for food and drink products are stored in RIF Storage and anchored on Rootstock via cryptographic hash proofs, enabling tamper-proof verification and auditability. Consumers and distributors access verified product histories through QR codes linked to a public Trace Viewer showing batch timelines, timestamps, and Rootstock transaction IDs. The project showcases how Rootstock can democratize enterprise-grade data security and transparency—currently accessible mainly to large corporations—by providing the target users with an affordable, easy-to-adopt blockchain solution that enhances compliance, trust, and competitiveness across intra-EU trade. The MVP demonstrates how blockchain-backed traceability can provide tamper-proof verification, auditability, and transparency for the food industry.
The idea that originated this project is to allow MSME (Micro, Small, and Medium Enterprises) producers, Artisans, and small Farmers, to access enterprise-grade data security through blockchain technology, ensuring that traceability and compliance data are protected against tampering, loss, or unauthorized modification. Most of these users produce food/ drink products but lack a verifiable, tamper-proof digital traceability layer.
As stated before, the project democratizes access to advanced data security which currently is almost exclusively accessible to large corporations that can afford it.
While traceability is the core objective of this project, leading food operators are already using digital traceability technologies to provide consumers with rich product information beyond what fits on physical labels, gaining a clear competitive advantage at the point of sale. This direct connectivity with the final consumer is increasingly influencing purchasing decisions, making it difficult for small producers to compete regardless of their product being the better option.
This project will provide the target user with an affordable, secure, and easy-to-implement traceability solution, enabling them to offer the same level of consumer transparency through QR codes linked to trusted blockchain-secured data. By empowering small operators to communicate authentic product information directly to consumers, the solution will strengthen competitiveness, authenticity, reduce food fakes, food fraud, and enhance overall food quality across all stages.
The project is not an exploratory pilot; it is a production deployment, with real supply-chain participants and defined operational workflows. The system’s usage is tied directly to ongoing business activity rather than experimental adoption, and each stage of the project is designed to produce tangible, measurable on-chain interactions. It will be structured to scale across a large, active network of participants.
Problem Statement
MSME food producers, artisans, and small farmers continue to rely on outdated, paper-based or manually maintained traceability systems that lack data integrity, verifiability, and transparency. These limitations prevent international buyers and consumers from fully accessing trusted product information and restrict producers from communicating the full value of their products. Enterprise-grade, tamper-proof digital traceability solutions exist but remain financially and technically inaccessible to this segment. This project addresses the gap by introducing an affordable, Rootstock-anchored audit and traceability mechanism, leveraging Bitcoin-secured infrastructure to deliver permanent, trustless proof of product integrity for micro, small and medium-scale operators.
Most target users lack knowledge of cryptocurrency, and the term ‘crypto’ often serves as a barrier to adoption for those unfamiliar with it. To ensure broader adoption, we’ve designed the platform to be simple and user-friendly, avoiding jargon and complexity.
Adoption
This project is designed for users who are not familiar with blockchain but the main difference is that they will not be interacting with crypto technology, the on-chain interactions will be carried out by us under the hybrid wallet model. This methodology is to encourage broader adoption of the service.
Blockchain technology is the base that the project uses for certifying the validity of the data, while very few customers will really understand the technological reasons why we have selected this approach as the best solution for this project, what they will understand is:
· The technology allows great communication to the final consumer.
· It meets all the EU safety standards for the Food and Drink sectors as reports and storage cannot be altered. Governmental agencies in charge of governing the sector will accept them as valid proof of traceability records.
· They will be able to do what the big companies are doing through the incorporation of QR technology at a minimal cost.
· Their peace of mind comes from the fact that they don’t have to understand the technology first hand but just trust it, as all of the above is based on a technology that is the safest in the market, with a level of security as good as the one used in internet banking or Paypal.
Blockchain will also play a fundamental role in our marketing campaigns as the technology’s perception as the most secure technology available keeps growing every day, and that sustains our business model.
We see this proposal as a complementary expansion of Rootstock’s core values.
The relevance for sellers (manufacturers, packers, producers) of using blockchain will be one more selling point when making their proposals: their products count with an impeccable secure traceability and enriched QR data deployment.
The fact that by using this service I can bring transparency, enriched information, and trustworthiness to my operations as a MSME/ Artisans/ Small Farmers is huge: the non-adoption of private quality marks and not being able to afford the use of this type of service, are two of the main barriers of entry to sell to the big distributors/ retailers.
The relevance for buyers is that they are buying a product that has been traced from its manufacturer and contains more information available for the final consumer to make their choice. All this based on blockchain technology.
The solution has been designed so it that there is no need to change the ways MSME/ Artisans/ Small Farmers are recording their data, we are not pushing the implementation of RFID, or the implementation of I/O Devices to capture data (that would also require investment in training). We are encapsulating the data and making it secure, reachable and shareable.
Following the premise of keeping the level of IT knowledge required to use the system to a bare minimum, the user will be interacting off-chain through the project’s website exclusively. A custodial wallet will be created upon verification of the registration process (for decentralization of the information purposes). The user will input data into the web based forms and send the hash request. The hashing will be done through the relayer wallet (pays gas), and the hash will be anchored on the user’s custodial wallet, as well as in the relayer wallet.
Why Rootstock
Rootstock adoption is ideal as it expands beyond DeFi into real-world verification and compliance use cases secured by Bitcoin. Crucially, the project makes this level of data security accessible and affordable for small producers, removing a major competitive barrier.
Rootstock is also ideal due low transaction fees, and EVM compatibility ratio. RIF Storage enables decentralized data hosting suitable for food supply chain trace files. Rootstock’s efficient gas model allows consistent daily anchoring for production operations, making blockchain traceability economically viable for real-world use cases.
· Blockchain-based data integrity, security, and immutability
o Data cannot be altered retroactively
o Records are verifiable and auditable
o Trust does not rely on a single central authority
Rootstock’s core narrative is ultimately about Bitcoin-grade security applied to real-world guarantees. While our end users may not interact directly with crypto, the value they receive — immutability, censorship resistance, and long-term verifiability — is entirely rooted in on-chain security and self-sovereign infrastructure. In our model, self-custody and on-chain interaction are preserved at the infrastructure and operator level, rather than pushed onto non-technical users who would otherwise be excluded.
This use case strengthens Rootstock’s ecosystem in three concrete ways:
1. It generates consistent, non-speculative on-chain activity that is independent of DeFi cycles.
2. It creates demand for Rootstock from service providers, integrators, and enterprises, many of whom are crypto-native behind the scenes even if their customers are not.
3. It reinforces Rootstock’s positioning as the Bitcoin-aligned chain for high-integrity, long-lived commitments, not just financial primitives.
Rather than diluting the narrative, we believe this demonstrates how Rootstock can extend Bitcoin’s security guarantees into real-world systems — without compromising its core principles.
We are committed to run the business on Rootstok and that will not change. We also count on incorporating solutions developed by the collective that will make the service better and stronger.
When we designed our service offer we did it knowing that most of our users are not be interested on managing their own wallet at this stage; they will want to enjoy the benefits of the service without having to add a new level of responsibility for using the service.
For those companies that value self custody and onchain security, they will be informed on the technical side of the service (and that is one of the reasons we picked Rootstok), and we will try to accommodate the best solution to keep them with us (if we have not implemented a service level were the users can have their own wallets).
This is all about supplying an effective, secure and cost effective product, and to do so we plan to use Opentimestamps [OTS – an open-source timestamping system that uses the Bitcoin blockchain to prove that a piece of data existed at or before a certain point in time] to keep our costs as low as possible without compromising any other part of the project.
For a traceability project to succeed it can not be about the cheapest provider, it has to be about being cost effective. It is about building a robust solution that prioritizes the core needs at the right price, and we feel that Rootstok is the one that can provide us with it along with:
· Longevity of proofs
· Auditability years into the future
· Independence from short-lived or experimental networks
Rootstock aligns with our long term trust model, as its close alignment with Bitcoin’s conservative, security-first philosophy makes it a better fit for these requirements than faster-moving, lower-cost EVM chains.
Once grant funding ends
Once grant funding ends, our incentive to continue anchoring on Rootstock is structural rather than short-term cost driven. The core value of our service is providing long-term, verifiable data integrity guarantees, where security, immutability, and credibility are more important than minimizing transaction fees.
Rootstock’s security and direct relationship with Bitcoin’s hash power provide assurances that low-cost EVM chains cannot replicate. Because our end users do not interact directly with crypto, transaction costs are absorbed at the service level and priced into our business model, allowing us to prioritize stability and trust over marginal fee savings.
We like the fact that Rootstock combines Bitcoin-level security with EVM compatibility, enabling efficient development without compromising the permanence and auditability our use case requires. Migrating to another EVM chain would introduce fragmentation of historical proofs, additional operational complexity, and reputational risk, while weakening the long-term guarantees we offer. For these reasons, Rootstock remains the most appropriate and durable foundation for the project beyond the grant period.
Information on the Project
Project stage: Early development / pre-MVP
Current status as of today:
· Core traceability data model, Data Collection & Regulatory Compliance (Design Readiness)
The project has already identified the common structure of the design of the web-based data input forms that will be used throughout the system. These forms cover the full user data-entry process, including required fields, formats, validation rules, and supporting information needed to ensure regulatory compliance.
The data model and input workflows have been designed to align with the following EU regulations:
· Regulation (EC) No. 852/2004 on the hygiene of foodstuffs
· Regulation (EC) No. 853/2004 laying down specific hygiene rules for food of animal origin
· Regulation (EU) No. 1169/2011 on the provision of food information to consumers
While food products are currently excluded from the initial scope of the EU Digital Product Passport (DPP), the system has been designed with a data input architecture and forward-looking approach anticipating that most future DPP data and traceability requirements will eventually become applicable to food products. As such, the project is positioned to support a smooth transition once food is included.
· Initial system architecture defined
Main components, data flows, blockchain role, and wallet model have been designed and agreed upon, providing a clear blueprint for MVP implementation.
· Rootstock selected as target blockchain
Sector: Infrastructure (Blockchain-based traceability & data integrity)
· Non-DeFi, real-world utility
· Strengthens Rootstock as a trust and verification layer
· Demonstrates Bitcoin-secured use cases beyond finance
· Aligned with supply chain, certification, and compliance narratives
Use Case: Blockchain-based traceability, proof-of-existence, and data integrity. What we are looking Rootstock to provide:
· Trust layer for traceability
· On-chain verification
· Data integrity for supply chains
· Blockchain-backed record keeping
Target Users and Market Scope: The traceability system is targeted at artisans, micro, small and medium-sized food and drink manufacturers and packers, small farmers, as well as producers operating under Protected Designation of Origin (PDO/AOP) and Protected Geographical Indication (PGI) schemes. In its initial phase, the project focuses on intra-Community trade within the European Union, ensuring harmonised data capture and compliance across Member States.
The focus on intra-community trade within the European Union, will ensure compliance with EU regulatory frameworks and cross-border traceability requirements.
Each user will be able to record all mandatory traceability data alongside optional product information of their choosing, including, quality certifications, awards, ingredients, region of origin, sustainability attributes, and marketing content.
In compliance with EU legislation, every batch of production has to be assigned a unique batch identifier to ensure end-to-end traceability. Each batch will also be linked to a blockchain transaction (TRX), creating an immutable and verifiable record. This inherently democratized approach is designed to serve over 80% of enterprises classified as MSMEs, that represent more than 235,000 European food manufacturers, over 240,000 wineries, 2,400 distillers, and 8,000 breweries, excluding small farmers selling directly to retail (we are targeting the major global food and beverage brands).
Our approach differs from others in that the blockchain layer is fully abstracted away: companies continue using familiar systems, while the anchoring of critical data to Rootstock is handled by the service provider as part of compliance, auditing, or certification workflows. Our project does not require behavioural change, token interaction, or direct blockchain adoption by industry participants.
We are currently engaging with mid-size producers, exporters, and traceability service providers, where regulatory pressure and audit requirements are more immediate and decision cycles are shorter. Success at this level creates credible, industry-validated reference implementations that can later scale upward. We also know that some of these big players will eventually become familiar with the service as we are planning to target organizations in which they are also members.
In short, we are prioritizing real integration paths and demand-driven adoption over early brand signaling, with the goal of avoiding the pitfalls that caused earlier initiatives in this space to stall.
Consumer Transparency, Market Access & Competitive Fairness
While traceability is the core objective of the project, it is increasingly evident that large operators are using traceability technologies not only for compliance, but also as a consumer engagement and marketing tool—often via QR codes that extend beyond what can fit on physical labels—large companies gain a significant marketplace advantage.
We also want our target Users to be able to provide consumers with what large corporations are doing now (not all these data fields are included but we foresee the advantage of being able to include them when available):
· Detailed origin and production data
· Quality indicators
· Storytelling and contextual product information
· Sustainability Proof data: Sustainability certifications, Provide CO₂ footprint, fair-trade scoring, or trace-to-farm ESG metrics.
This trend has shifted consumer decision-making:
· Product quality alone is no longer the primary differentiator
· Transparency, information, and trust play a growing role
Small producers, despite offering high-quality and authentic products, often lack:
· Technical expertise
· Financial resources
· Access to existing traceability service providers
Project Impact
This project enables small producers to:
· Access a simple, affordable, and compliant traceability solution
· Display QR codes on product labels, comparable to those used by major operators
· Provide consumers with trusted, verifiable product information
· Strengthen protection against food fraud and misrepresentation
· Compete more fairly in an increasingly digital and transparency-driven market
By democratizing access to advanced traceability and consumer-facing transparency tools, the project represents a game-changing opportunity for artisans and SMEs across the EU food sector.
2 Team Background
Marcos Black (Project Manager): Business Developer and project designer. HACCP consultant. Complete food factory layout design for the three factories from where the company has been operating during the last 13 years (from concept to finish product). Design and implementation of HACCP compliance at European level for each of these factories. Extensive experience in traceability, dealing with high demanding quality departments in top clients for companies in different sectors: retail (supermarkets and forecourt, restaurants, cafes and pub chains, breweries, and caterings). 10 years of experience in Tech Finance Sector and 13 years in the Food and Drink Sector.
In addition to Marcos, the team includes a project analyst experienced in designing IT process solutions, gathering and documenting user requirements, mapping workflows across nine European markets, overseeing testing and bug reporting, and producing user manuals after final approval.
This initiative is not a DeFi or purely technical protocol, but a traceability tool designed for the manufacturing and distribution of tangible products operating under regulatory and operational constraints. Based on this reality, we have deliberately structured the team around four complementary domains, with IT being one—rather than the sole—pillar of execution.
The project is executed by a multidisciplinary team designed for real-world traceability adoption, where IT development is guided and constrained by commercial, regulatory, and operational expertise rather than isolated technical experimentation.
-
Commercial (in-house)
Responsible for market adoption, user onboarding, and commercial relationships with suppliers and clients. This team serves as the primary point of contact with users and is initially responsible for collecting user feedback and operational insights to inform continuous platform improvements.
-
Health & Safety / HACCP (in-house)
Responsible for the traceability, compliance, and audit requirements that define the functional scope of the system. This domain expertise ensures the platform reflects real regulatory workflows rather than purely theoretical designs.
-
Project Management (in-house)
Acts as the coordination layer between Commercial, Health & Safety, and IT development. This role is responsible for defining process flows, translating real-world requirements into technical specifications, and ensuring milestones and deliverables remain aligned with operational needs.
-
IT Development (outsourced)
Responsible for the end-to-end technical development and implementation of the platform, including architecture, blockchain integration, and delivery of milestones. This role operates under clearly defined specifications, milestone-based accountability, and continuous oversight from the in-house team. Outsourced to: Martin Durnhofer – Co-Founder Hornerorojo // https://www.linkedin.com/in/martin-durnhofer-862b672a?trk=blended-typeahead
This structure reflects how traceability systems are successfully deployed in traditional industries: technology serves the operational and regulatory model, not the other way around. The project’s execution risk is therefore mitigated not by relying solely on a single technical team, but by anchoring development in established commercial, compliance, and project management expertise. While IT capability is essential, the project’s success depends on a broader real-world execution framework, which is already in place and directly aligned with the proposed milestones and deliverables.
About the Company
Mora Foods Ltd is a small-sized SME that produces high end niche food solutions to European customers. We intentionally designed our Food Safety Management System to the standards expected by large production enterprises, ensuring our products are ready for adoption by major buyers. Our system is fully managed and supported in-house, and that has allowed us to supply the most demanding clients in terms of food safety.
All production is carried out in a 12,000-square-foot facility, supporting a wide range of product lines tailored to the various distribution channels. The company exports throughout the European Union, Great Britain, and Switzerland, and offers both ready-to-eat and ready-to-cook solutions. The company has developed an award-winning recipe portfolio that has earned a total of 48 gold medals across 12 distinct product ranges over the past 13 years.
Sustainability has long been a core principle for us, so in 2017 the company became a frontrunner by adopting a formal sustainability program in food production. The launch of this program at a national level exposed a clear gap: while reporting requirements were defined, practical digital tools to support them were largely unavailable.
Food safety is paramount for any food producer, and effective traceability is critical to the rapid identification and recall of products that may fail at any stage of the production lifecycle. At that time traceability was required by the authorities to be kept documented on paper, we needed a more reliable option so we developed an internal bidirectional traceability system to meet the stringent conditions imposed by the quality departments of major clients. Although basic from a technological perspective as it is based on excel, this system—still in use today—enables full forward and backward traceability and has consistently met, and in many cases exceeded, the food safety standards set by national authorities derived from European legislation.
This is further reinforced by a robust quality management system, an efficient, privately audited recall process, and a specialty-driven approach as a certified gourmet food producer. As our product range is both unique and highly niche, this level of capability of supply is uncommon for a company of our size. However, maintaining this structure involves significant ongoing costs.
In terms of Technology
We are an early-stage startup in what it refers to technology. In this project we will be sharing in the investment costs as we will be funding a part of the IT costs, and 100% of the non-IT costs during its first year of operation that include fixed and HR costs. We are contributing domain expertise, operational resources, and long-term maintenance, and we are committed to deploying and operating the system beyond the grant period. We will absorb costs related to client onboarding, off-chain operations, HACCP design architecture prior to validation, technical consultancy on Food Safety, and commercial deployment, while the grant is specifically scoped to protocol integration and on-chain usage.
3 Total Grant Amount
[$X 19.200; requesting $8.000 for Milestone 1]
4 Value Prop for Rootstock: This project will make use of open-source tools, and feedback along with user experience insights will be shared following implementation. As the project continues to evolve, we anticipate incorporating additional community-driven solutions, enabling real-time insights from their deployment. Future development plans include the integration of digital identity features once users are comfortable with the platform. The pace at which new crypto-based tools are introduced will be guided by the maturity and readiness of the user base.
Although on-chain access is centralized at the operator level, Rootstock usage scales with real-world activity rather than the number of wallets. Each additional client, product batch, or supply-chain event processed through the system results in incremental on-chain transactions, regardless of whether end users interact with the network directly (for those future cases that would merit us to explore supplying this type of service).
As adoption grows, the volume and frequency of on-chain writes and verifications increase proportionally, ensuring that Rootstock benefits from sustained, non-speculative usage tied to economic throughput. The architecture also preserves the option to evolve toward multi-operator or direct-access models if regulatory or operational conditions change, without requiring changes to the underlying protocol.
From the Rootstock point of view, it should also be brought into consideration that the strength of the business model relies on the fact that the hashing of batches is of food and drink products, essential products that are being produced and consumed daily.
As the project is designed around a hybrid adoption model that reflects current industry constraints while maximizing long-term on-chain value for Rootstock, Mora Foods will operate the on-chain interface and acts as the primary network participant, while thousands of downstream supplier and client businesses consume the traceability service off-chain as part of their day-to-day commercial operations. This approach significantly reduces onboarding friction for non-technical users, while still ensuring that real economic activity is consistently anchored to Rootstock.
So the project will deliver ROI to Rootstock through sustained, enterprise-driven on-chain usage tied to real economic activity, while onboarding new users into the ecosystem via a pragmatic, progressively decentralized traceability model.
Direct ROI for Rootstock
· Sustained on-chain usage tied to real-world activity:
All traceability events (document hashes, timestamps, verifications) are anchored on Rootstock via a relayer wallet. As commercial adoption grows, the volume and frequency of on-chain transactions scale proportionally, generating continuous, non-speculative network usage.
· Enterprise-driven throughput:
Unlike short-term DeFi activity, traceability generates recurring transactions driven by supply chain operations, audits, and compliance requirements.
· Wallet creation and ecosystem entry:
Each user registering for the service is assigned a personal wallet, which is used to cryptographically associate their document hashes on-chain, introducing new users to the Rootstock ecosystem.
Collective Ecosystem ROI
· Non-speculative demand:
Usage is directly linked to economic throughput (production, logistics, compliance), creating predictable and sustained demand for Rootstock blockspace.
· Crypto adoption incentives:
Users are incentivized to pay for the service using a selected group of crypto (RBTC, RIF, USDRIF, MOC, DOC, BPRO) through discounts. The platform will provide guided onboarding, including wallet usage, acquiring crypto, and making payments—lowering barriers for new entrants.
· Use of timestamps and verifiable proofs:
Each on-chain anchor strengthens Rootstock’s positioning as an infrastructure for verifiable, real-world data integrity.
· Progressive decentralization roadmap:
As users become more familiar with blockchain tooling, we have contemplated for future designs for the system to incorporate the use of smart contracts and fully decentralized interactions, without alienating early adopters.
· The implementation of this project can act as a feeder for a future Proof of Productive Behavior (PoPB) project developed by someone else in the Collective.
Decentralization Model (Phase 1 – outlined in this MVP)
To balance usability and decentralization during onboarding:
· Each document hash is anchored on-chain with the user’s wallet recorded as the primary cryptographic owner.
· A company-controlled wallet is linked only as a secondary reference, providing continuity and support in cases where users lose access during early adoption.
· The relayer wallet submits transactions and pays gas, but does not own or control the data. This ensures:
· Users can never be removed from the on-chain history of their data.
· The company cannot revoke, alter, or override ownership.
· All records remain immutable, verifiable, and auditable by third parties.
Decentralization Long-term Alignment
The company acts as a secondary attester and operational facilitator, not a custodian. As adoption matures, reliance on the relayer and secondary references can be reduced, enabling a transition to full user-only ownership and smart-contract–driven workflows.
5 Milestone 1 Deliverables (USD 8.000)
· European HACCP Validation from the eight markets (GB, France, Germany, Spain, Italy, France, Ireland, Portugal).
· Off-chain web-based process for traceability data submission
· Backend service to normalize data and generate cryptographic hashes
· Hash anchoring using simple blockchain transactions
· Basic transaction submission from backend to Rootstock through Relayer Wallet
· Manual testing of end-to-end data flow
· Add input validation and data normalization
· Prevent duplicate or overwritten records
· Implement access control (authorized submitters)
· Traceability mapping for 8 products
· JSON schema for trace files
· RIF Storage integration
· Backend prototype for event → trace file → RIF upload
· Rootstock testnet anchoring pipeline
· Public verification endpoint (check product ID → hash)
· Off-chain data vs on-chain hash comparison
· Simple verification UI
Outcome: Validated European design, achieve a safer, predictable on-chain behavior. Third parties can independently verify data integrity.
6 Milestone 2, 3 & 4
Milestone 2: Wallet & Transaction UX - Month 2 (USD 4.600)
· Off-chain web-based Registration and creation of User Autocustodial Wallet Beexo
· Off-chain web-based website design
· Off-chain web-based Validation Step
· Replace private key usage with wallet-based signing
· Clear transaction status feedback
· Error handling and retries
· Event capture interface for production workflows
· Automatic creation of trace files per batch
· Rootstock anchoring for real tests (4 products)
· Rootstock anchoring for products sold at different channels
· Internal batch viewer (alpha)
Outcome: Registration process and creation of user wallet. Website design. User-safe blockchain interaction.
Milestone 3: Off-chain Storage Integration and Pilot Deployment – Month 3 (USD 3.000)
· Off-chain web-based website reviewed, update and sign off
· Store full traceability records in database or IPFS
· Link off-chain data to on-chain hash
· Complete Testing Relayer Wallet and payment for gas
· Ensure GDPR / data privacy compliance
· Deploy on RSK testnet (or mainnet with limited scope)
· Onboard 1–2 pilot users or organizations
· Collect feedback on UX and performance
Outcome: Production-ready data architecture Beta release (real users, real data, limited scale)
Reaching the Beta stage (for Rootstock)
· Once the project progresses to Beta, pilot users will submit and verify real traceability data on Rootstock using wallet-based standard transactions, without relying on smart contracts.
Milestone 4: Pilot Deployment – During month 4 (USD 3.600)
· Public Trace Viewer + QR codes for 8 products
· Mainnet deployment
· Gas usage and operational cost report
· Full documentation + demo video for the Rootstock Collective
Outcome: Demonstrates real-world usability, proves consumer-facing transparency, and validates the end-to-end traceability flow.
7 Milestones to reach Beta
· Public verification endpoint and UI
· Wallet-based transaction signing (no private keys on server)
· Off-chain storage (DB or IPFS) linked to on-chain hashes
Pilot deployment with real users
8 Pilots and validation
We will use Mora Foods Ltd as the first pilot operator for eight products, once we are happy with the first results we will immediately add an SME manufacturer which they have already agreed to participate in this stage.
The company has been a member of different networks of manufacturers at local and national level since its beginning. Once we are happy with how the system performs after collating results from the first two operators, our plan is to add one successful restaurant group that also sells their sauces in the retail sector (supermarkets and specialty shops), and one Meat factory or Beef Farmer. The aim is to keep adding one type of pilot user from each sector to whom we plan to market the service to: artisans, packing companies, farmers, micro manufacturers, larger SME’s manufacturers. This will allow us to get some real feedback on the off chain side from each sector/ segment/ type of user: feedback on the user experience, suggestions to incorporate new data fields, suggested amendments. With more pilot users we will end up with better data to analyse the on-chain side of the project.
The pilot participants represent different segments within this network and are intended to serve as reference cases across the four stages. This approach enables the development of validated documentation, including a technical white paper and supporting materials, which will be used to support broader adoption. As adoption expands across these organizations, operational activity will scale proportionally, resulting in a significant increase in batches processed and recorded on the Rootstock network.
This will allow validation of the MVP using real data, real operational workflows, and all under concrete regulatory requirements within the EU.
After validation, as we have included in the pilot stage companies that are producers and processors from two industry organizations we belong to. Their involvement reflects existing interest and operational alignment, rather than hypothetical demand, reflecting real operational interest. This means that after completing the four pilot stages, the initial rollout is planned at the organizational level, potentially reaching 60,000 farmers, 100 meat processors, and 500+ associated companies.
9 Timeline: Start immediately after approval.
End at 110 days with 4 completed milestones.
10 Technical Specs: PROJECT SCOPE AND COMPONENTS
SCOPE: Traceability MVP for 8 products using RIF Storage (IPFS) + Rootstock anchoring. No smart contracts required.
COMPONENTS:
A. RIF Storage Integration
- Store batch-level JSON trace files in RIF Storage.
- Each file includes traceability origin data, processing timestamps, batch ID, and other selected information.
B. Rootstock Anchoring
- A simple Rootstock transaction stores the hash of each trace file.
- Anchoring includes product ID, batch ID, and timestamp metadata.
- No smart contract required for MVP.
C. Event Capture Middleware
- Backend service to collect and aggregate production events into trace files.
- Automatic upload to RIF Storage and hash submission to Rootstock.
D. Public Trace Viewer + QR Codes
- QR printed on packaging for 8 products.
- Consumers access a page showing trace data, Rootstock transaction ID, and verification status.
- Internal dashboard to monitor anchored batches.
MVP approach: simple transactions vs. smart contracts
For the MVP, the preferred and recommended approach is to use simple transactions on Rootstock, without smart contracts. The main reason is that the goal of the MVP is to clearly and verifiably demonstrate:
· Proof of existence
· Data integrity
· Independent auditability
· Immutable timestamps
Under this scheme:
· Data is processed and normalized off-chain
· A cryptographic hash is generated
· This hash, together with minimal metadata (product ID, batch, and timestamp), is anchored via a standard transaction on Rootstock
· The complete files are stored in RIF Storage
This approach is what we found to be the one most closely aligned with Bitcoin at this stage, as it reduces attack surface, operational costs, and unnecessary complexity, while maintaining clear auditability backed by Bitcoin’s inherited security through merged mining.
The incorporation of Smart Contracts will be done in a future phase of this project to fully decentralized interactions (can not be done at this stage as target market is comprised by mostly novice users).
To put this in context, at the MVP stage we do not want to incur in the following:
· Higher gas consumption per operation.
· Introduction of additional costs in deployment, maintenance, and review.
· Increment of technical complexity as it does not provide any direct benefits to the MVP’s primary objective.
So while we do not fully discard the notion of incorporating smart contracts, we consider it more prudent to reserve them for later stages (Beta or production). Instances that would result in their implementation: a need for on-chain logic, decentralized role control, or interoperability with other contracts (this does not guarantee their incorporation, only that we have identified a solution if any of the instances mentioned before happened).
Single wallet approach (Backend-controlled wallet) vs Per-user wallet approach (User-controlled wallets) vs Hybrid approach (practical for MVP / Beta)
While looking into the three options’ pros and cons, we have decided to select a hybrid approach to the solution; most users will not have any crypto knowledge at all. The word crypto acts like a barrier of adoption in many cases for common web users if not familiar, and to achieve a high adoption rate we want to keep it simple. We have identified these main advantages:
· Simple UX for users — no crypto knowledge required.
· Backend controls all blockchain interactions.
· Preserve auditability per user.
· Easier for MVP: no MetaMask or wallet integration.
- Faster Adoption: removes the barrier to entry for non-crypto users, especially in early adoption stages (MVP).
The model will include:
· Backend uses single wallet for transaction submission.
· Each record still includes user ID or organization ID in the data payload.
· Hash of user-submitted data is stored on-chain.
· Verification can still prove which user submitted what, even though blockchain sees only the backend wallet.
· Once we reach Beta, we could optionally migrate to per-user wallets for scalability.
FACTS
· Use one wallet controlled by the traceability platform at MVP stage.
· Include user/organization metadata in the hash before storing it on Rootstock.
· Once you reach Beta, you can optionally migrate to per-user wallets.
Hybrid Wallet (Backend-Controlled) Approach:
-
Single wallet owned by the supplier is used for all blockchain interactions.
-
User data (e.g., ID or organization ID) is included in the transaction to provide proof of who submitted the data, but the blockchain interaction itself is managed by the backend.
-
The backend manages all wallet transactions, meaning the clients (users) only interact with a web form to submit their data — they do not need to worry about MetaMask, private keys, or cryptocurrency.
How It Works:
1. User submits data (via web form).
2. Backend hashes the data and prepares the transaction.
3. Backend submits transaction using the supplier’s wallet (which holds the private key).
4. Blockchain stores the hash with user/organization metadata for traceability.
5. Verification is possible, proving which user/organization submitted what, even though the blockchain only sees the supplier’s wallet.
Advantages of This Model:
· Simple User Experience: Users don’t need to worry about setting up wallets or handling cryptocurrencies.
· Backend Security: The backend ensures secure handling of the wallet, which is the only part that needs to be protected.
· Faster Adoption: Reduces the barrier to entry for non-crypto users, especially in early adoption stages (MVP).
Custody and access control model
The MVP will use a custodial wallet model with individual user wallets and a company-owned relayer wallet. User wallets anchor hashes on-chain, while the relayer generates hashes, submits transactions, pays gas fees, and keeps secure backups. All private keys are securely managed via AWS KMS, with backend-controlled transaction signing and strict access controls.
This approach is intentionally chosen for the MVP to:
· Reduce user friction and avoid direct key management for non-crypto-native users
· Minimize operational complexity and attack surface
· Enable reliable, auditable anchoring of hashes on Rootstock via simple transactions
Identity and future direction
At this initial stage:
· Identity is managed off-chain
· We avoid introducing premature or non–Bitcoin-aligned identity solutions
The project will always contemplate the integrating of decentralized identity solutions in the future if that is the best path to follow, provided there is clear ecosystem consensus, and such solutions deliver real value without compromising core principles.
MVP scope (Tasks to be completed)
· Web-based form for traceability data submission
· Backend service to normalize data and generate cryptographic hashes
· On-chain hash storage implemented on the Rootstock testnet using standard transactions
· Basic transaction submission from backend to Rootstock
· Manual testing of end-to-end data flow
Off Chain Technical Aspects
This project does not offer data verification. The reason is because if you are registered and licensed by the authorities to sell food and drink, you need to keep records that can be audited by them, and this responsibility is not transferable. As these records are audited by the authorities, the accuracy on the records is upon the producer.
Having said so, as I mentioned in the project description, the design of the traceability system is based to match requirements set by European Legislation. Each country then incorporates the regulations into their national legislation which is the base used for licensing and control. Each farmer/ artisan/ producer is responsible to comply with the requirements set by the law under which they have been granted a license (EU Regulations act like an umbrella setting the general requirements, and specific ones depend on the segment/ product – e.g.: enhanced specific rules records for animal products).
The principle of traceability is that businesses should track products “one step forward, one step back” (your supplier, and your clients) at all stages (production, processing, distribution) for safety and recall.
Basic Validation to ensure that the anchored data reflects reality
Regardless of the fact users are still responsible for the accuracy of the information input by law, we have incorporated in the off-chain part of the design the option to set rules and formats that will support them during the input process:
· Differentiation between required and optional fields
· Rules for fields L1 (populated with company information)
· Rules for fields L2 (populated with product information)
· Rules for fields L3(populated with batch information)
· Rules for fields L4(populated with supplementary information)
All these fields will have a specific format that will have been identified in the Milestone #1 when we validate the design at country level.
This formatting feature is already available in most labelling software, and all companies are familiar with them so there is no behavioural change. It allows the admin user to define the label format during the setup of each product. As a result, only certain fields can be updated by regular users, and the data input for those fields is restricted to a specific format (these fields are set as Variable keyboard input).
As an example, the software we use allows you set the Variable keyboard input fields by defining the following:
Ø Define Data Type (text, date, time, batch, count)
Ø Data Format
o Define initial and provisional values
§ Define prompting
§ Input Rules
§ Output rules
As a result of how we did the setup on our labelling system, when a regular user opens a product label for printing, there are three prompts that appear before allowing the user to print the batch of labels, which in our case are: production date, shelf life date, and batch. While the first two fields are defined as date (DD/MM/YYYY), the batch field has been set with a data length set at 10 characters and follows the format we chose and was accepted by the authorities during the licensing process:
We designed our batch as the following: DDMM- XXXZZ, where:
o DD: day (Numeric)
o MM: month (Numeric)
o –: separator (Alphanumeric)
o XXX: internal product code (Numeric)
o ZZ: internal range code (Text)
Users currently register their batch information using their own preferred format. Once registered, they will be able to select from a dropdown list of common formats or upload a custom format, which the platform will support by helping define and structure the batch field values.
11 Video Pitch:
https://drive.google.com/file/d/1mU4UkdtLsYR_ubCXEJBuJgW9ApKJQp-c/view?usp=sharing