-
Project Name & Description
MORA Trace Ledger – Blockchain-Anchored Transparency for Food and Drink ProductsThis 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.
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.
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. 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
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 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.
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.
1.1 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 traceability, dealing with high demanding quality departments in top clients for the 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.
Mora Foods Ltd is a food manufacturing company supplying premium, high-end products to customers across Europe. Over the years, the company has developed and supplied products to food distributors, leading supermarket chains, forecourt retailers, and pub chains, while also consulting for major brewing companies. It produces and has co-developed concepts and recipes for numerous successful and well-established restaurants, gastro pubs, cafés, and food producers.
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 and derived from European legislation.
-
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 traceability, dealing with high demanding quality departments in top clients for the 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.Mora Foods Ltd is a food manufacturing company supplying premium, high-end products to customers across Europe. Over the years, the company has developed and supplied products to food distributors, leading supermarket chains, forecourt retailers, and pub chains, while also consulting for major brewing companies. It produces and has co-developed concepts and recipes for numerous successful and well-established restaurants, gastro pubs, cafés, and food producers.
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 and derived from European legislation.
-
Total Grant Amount
[$X 26.800; requesting $10.500 for Milestone 1] -
Milestone 1 Deliverables
· European HACCP Validation from the eight markets (GB, France, Germany, Spain, Italy, France, Ireland, Portugal).· Web-based form for traceability data submission
· Backend service to normalize data and generate cryptographic hashes
· Smart contract deployed on Rootstock testnet to store hashes
· Basic transaction submission from backend to Rootstock
· Manual testing of end-to-end data flow
· Add input validation and data normalization
· Prevent duplicate or overwritten records
· Implement access control (authorized submitters)
· Internal smart contract review
· Supply chain 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.
-
Milestone 2, 3 & 4
Milestone 2: Wallet & Transaction UX - Month 2 (USD 7.500)· Replace private key usage with wallet-based signing (MetaMask or RSK-compatible wallets)
· 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: User-safe blockchain interaction
Milestone 3: Off-chain Storage Integration and Pilot Deployment – Month 3 (USD 5.000)
· Store full traceability records in database or IPFS
· Link off-chain data to on-chain hash
· 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 be submitting and verifying real traceability data on Rootstock, wallet-based transactions, and a hardened smart contract architecture.
Milestone 4: Pilot Deployment - Month 4 (USD 3.800)
· 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.
-
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
-
Timeline: Start immediately after approval.
End at 110 days with 4 completed milestones.
-
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.
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’s 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 and pilot users, 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 and pilot users, 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).
MVP scope (Tasks to be completed)
· Web-based form for traceability data submission
· Backend service to normalize data and generate cryptographic hashes
· Smart contract deployed on Rootstock testnet to store hashes
· Basic transaction submission from backend to Rootstock
· Manual testing of end-to-end data flow
-
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.
-
Video Pitch:
https://drive.google.com/file/d/1mU4UkdtLsYR_ubCXEJBuJgW9ApKJQp-c/view?usp=sharing
Hi @Marcos_Moratrace , welcome to the Collective!
I’ve completed an initial review of the proposal to help the Collective assess scope, milestones, and overall alignment with Rootstock. At this stage, the concept and direction are clear, while some elements are still at a design or early-build phase, which limits deeper technical verification for now.
One small clarification on the technical scope: in some sections the MVP is described as using a simple Rootstock transaction without smart contracts, while elsewhere a smart contract deployment and review are listed as deliverables. It would be helpful to clarify which approach you’re planning to follow for the MVP.
A couple of additional quick points, just for clarity:
• The Team Background section appears twice in the proposal
• For the MVP, how are you currently thinking about key custody and access control for the backend-controlled wallet?
• Do you already have potential pilot users in mind from your existing producer network?
Any additional material you’re comfortable sharing would naturally help strengthen future reviews.
Hi @Marcos_Moratrace — thank you for submitting this proposal. It’s encouraging to see a traditional manufacturing company exploring open, permissionless blockchains. I have a few foundational questions, particularly since it appears this is your first time engaging with the Rootstock community.
-
How did you first learn about Rootstock and the Rootstock Collective?
-
Beyond Marcus, who else will be part of the project team? Who will be on the development team?
-
What prior experience does the team have with crypto and blockchains?
Lastly, I’d like to flag a point in your rationale under ‘Why Rootstock.’ You state that “Rootstock is also ideal due to low transaction fees.”
This is actually a nuanced statement. While Rootstock fees are lower than Bitcoin L1, they are significantly higher than many EVM L2 networks, so additional justification or context here would be helpful.
HI @Kaf_StableLab, thanks for the welcome. Excited to be here!!
Apologies on the delay getting back, spent the day traveling on Friday and fought the flu on the weekend, so ready to get back into it with a clear head.
Thanks for picking up on this, when we first envision the project, we went with the smart contracts approach but along the way we have identified that the strength of the model relies on simplicity of use for our target users so we have changed and decided to go without smart contracts for the MVP. It seems that the final document I created had some bits from the earlier versions that I missed updating.
As you rightly point out, please see below a clarification on why we got to this decision that I have incorporated as a segment referred to the choice of simple transactions vs smarts contracts in the technical part of the project. All corrections in the final document have been made.
I have listed the four queries as A, B, C, and D.
A-Regarding the approach for the MVP: 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.
We do not discard using smart contracts in the future but only if deemed necessary
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 found a solution if any of the instances mentioned before happened.
B- The team background section appears twice in the proposal – that was fixed
C- Regarding key custody and access control for the backend-controlled wallet for the MVP?
Custody and access control model
For the MVP, we will be using a backend-controlled, custodial wallet model. Private keys are generated and stored securely using a managed key service (AWS KMS) and are never exposed in plaintext. Transaction signing is performed by the backend service, with access restricted via service-level permissions and environment isolation.
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.
D-Regarding 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. 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.
This will allow validation of the MVP using real data, real operational workflows, and all under concrete regulatory requirements within the EU.
In summary, for the MVP we believe that not using smart contracts is not a limitation, but rather a responsible, efficient design decision that aligns with Rootstock’s role as a pragmatic extension of Bitcoin.
We are, of course, fully open to continuing the discussion and revisiting these decisions in later phases, depending on the project’s evolution and feedback from the Collective.
Thank you once again for the comments and the opportunity to clarify these points.
Kind regards,
Marcos
This is a solid real world use case, I appreciate the effort to bring Rootstock into more traditional supply chain and traceability use cases.
That said, I do have a concern around alignment. Most Rootstock users are crypto native, builders, power users, and people who value self custody and onchain security. This proposal, however, is designed for users who are not familiar with blockchain and may prefer to avoid direct interaction with crypto altogether.
How do you plan to bridge this gap and make sure this use case strengthens Rootstock’s core ecosystem and narrative?
And once grant funding ends, what incentives exist for this project to continue anchoring on Rootstock specifically, rather than migrating to another low cost EVM chain?
Are there any major food and beverage companies involved?
I have seen various project likes this over the years(IE traceability in shipping), and they have all died because there is no interest from actual industry.
Hi @Ignas
Thanks for your question and glad that you have brought this point up.
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. 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.
· All of the above 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.
Don’t get me wrong, while we are not business of selling blockchain, our business is to make our target users understand that we have base the Traceability system on the most secure technology that is Blockchain.
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.
Protein enriched foods is a good example of this, people are still buying yoghurts, milks, drinks and ready meals, but now they have an option of choosing alternatives with a high protein content. That segment is growing at an incredible pace and in many cases is reshaping the offer. As a producer you still produce the same ranges but now with an alternative version with high protein content. This does not mean that they are in the business of selling Whey protein, they are still in the business of selling food but the whey protein is a new ingredient in the whole of the new range. I see blockchain as that new ingredient that we will integrate into our offer as the providers of the traceability solution. Target users will see it as the one thing that makes the whole process safe.
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 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.
We see this proposal not as a departure from Rootstock’s core values, but as a complementary expansion of them.
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; 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.
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.
Hi @CodeKnight,
Thanks for your query and this is a valid point as well. This is a valid concern, and we are intentionally approaching it with realism to avoid the same pitfalls that many similar projects encountered in the past.
From the research done when we were designing our business model, we also seen cases that did not progressed or die; many times due to the industry or players had no interest in implementing this, or just because it was focused on solving a problem that in many cases was not there.
The one difference is that there is a real problem, and we thought of our service as a way to solve, to complement, or to enrich and create opportunities that are not currently available for its target users. Many doors remain closed to them because:
· From the food safety point of view: they lack the level of technology to supply tamper evident traceability records. It makes it difficult to implement a fast an effective recall procedure.
· From a marketing side: they can not produce an enrich data package along with the batch code, making their product lack the option of instant knowledge at the shelf. Their products are losing market share to big companies that are using this technology.
· It is hard or too expensive to implement a system to guarantee their product origins (fight food fake).
Our project is not targeted to major global food and beverage brands. Our focus is on the rest of the companies that are more than 500K target users in Europe, without counting the farmers. The volume of hashes that this group will consume is huge and by adopting our service, many will eventually be able to become suppliers to the big players in the market. The focus is on building a practical, infrastructure-level capability that can be integrated easily by our target users.
In the past we have realised that many traceability projects failed because they required behavioural change, token interaction, or direct blockchain adoption by industry participants; and we do not want that. Our approach differs 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.
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 this 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.
Hi @404Gov,
Thank you for your feedback and for reviewing our proposal. We are excited to have developed this project be based on Rootstock’s blockchain. It is great that we can get to engage with the community as well. We look forward to providing more context on how our project aligns with Rootstock’s mission while delivering real-world impact. I have pasted your original queries below so their answers reads better.
- How did you first learn about rootstock and the rootstock collective?
We have been trying to develop this project for some years now and we were introduced to Rootstok through an acquaintance (Agustin Pandolfini) that used to work for IOV. We have mentioned to him about the needs of the project and the specifications of our target market. He was the one that introduce us to the Collective, and he championed the technology as a solution that can bring the level of security we required, along with the level of user experience that we aim, all on-chain interaction stays away from the target user.
- Beyond marcus, who else will be part of the project team? Who will be on the development team?
Apart from Marcos, we have a project analyst in the team with experience in designing out solutions for IT processes for Hertz Europe. In there he had designed the layout of solutions (gathering and documenting user needs), and documenting workflows of several projects that contemplate the processing of data from nine European markets. His experience was mainly in bridging the gap between technical teams and business needs, ensuring requirements were met. Once the solution was developed, he oversaw the initial testing, bug reporting, and final testing. Once approved by the head of the department, he created all the user manuals for that application.
In this case, the development of the solution will be carried out by developers that we know that work with this technology. They count with the technical knowledge that we need to get this done. They will be working along with Marcos and Sebastian.
- What prior experience does the team have with crypto and blockchains?
We do not have crypto and blockchain experience specifically but we are familiar with the implementation or development of projects using other technologies in the past. We see Blockchain as the new technology that we need to implement now, and we can see the benefits of this technology that is being incorporated more and more all over the world. We have experience in Traceability, and Blockchain provides us with the “material” to make this project bullet proof, which is the only way that a traceability project can be run.
- Lastly, i’d like to flag a point in your rationale under ‘why rootstock.’ you state that “rootstock is also ideal due to low transaction fees.” This is actually a nuanced statement. While rootstock fees are lower than bitcoin l1, they are significantly higher than many evm l2 networks, so additional justification or context here would be helpful.
From our point of view, 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 provides 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.
We will utilize OpenTimestamps to minimize operational costs while maintaining reliability.
Thanks,
Marcos
We do think what @CodeKnight just raised is a valid point.
From your answer, you mentioned that the project is mainly targeting small and mid-size producers, and that there are around three key pain points you are trying to address:
-
the lack of tamper-evident traceability for food safety and compliance,
-
limited ability to offer rich consumer-facing product transparency compared to large brands, and
-
the high cost or complexity of existing anti-fraud and origin-verification systems.
That framing makes sense as a justification for why blockchain is being used here.
However, we do still have a few questions we’d like to clarify:
-
How do you verify that the information entered by farmers or artisans into the web form is accurate, given that blockchain only guarantees immutability after submission?
-
What checks or validation mechanisms exist at the point of data entry to ensure that the anchored data reflects reality?
-
Do you already have producers who have confirmed interest or intent to pilot?
Hi @Curia,
Thanks your interest, these questions are perfect to go in depth on the off-chain side of the project. I have pasted your questions in the reply so it is easier to read.
- How do you verify that the information entered by farmers or artisans into the web form is accurate, given that blockchain only guarantees immutability after submission?
The short answer is that at this stage we will not be offering data verification (this is something that has been identified as a potential feature for the future depending on the user feedback/ experience or if required by an organization for its members). We will assist them at this stage so the information is as accurate as possible (details in the answer for the next question).
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.
- What checks or validation mechanisms exist at the point of data entry 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)
- Do you already have producers who have confirmed interest or intent to pilot?
Yes, we do. The plan is to run the pilot gradually, in stages:
Phase 1
· Mora Foods
· One food manufacturing company producing both own-brand and white-label products
Phase 2
· One restaurant group that also sells its sauces in the retail sector (supermarkets and specialty shops)
· One SME meat processing company
Phase 3
· One artisan food producer
· One company that purchases spices in bulk and packages them for retail sale
Phase 4
· One farmer
· One micro manufacturer
· One food supplement manufacturer
Thanks again and happy holidays.
Marcos
I did some research on what European producers are currently using to fulfill their logging and auditability legal requirements, as a foundation for what I wanted to ask, in the end of this post.
In light of collaboration, I’m sharing it below, as it may help others.
*this was a research made for myself, I cannot vouch for the accuracy of that information. Marcos feel free to point out any mistakes.
Current Practices in Europe
European food producers are indeed required by law to maintain traceability records that can be audited by authorities. The core regulation is Regulation (EC) No 178/2002 (the General Food Law), which mandates the “one step back, one step forward” principle:
- Producers must identify immediate suppliers (where ingredients/raw materials come from).
- Identify immediate customers (where products go next, except direct to final consumers).
- Keep records available for inspection on demand.
There is no mandatory internal traceability (linking inputs to outputs within a single business, e.g., how specific batches are combined in production), but many implement it voluntarily for better recall precision and efficiency. Additional rules apply for specific sectors (e.g., beef, fish, or animal-origin foods via Regulation (EU) No 931/2011).
How Producers Currently Maintain Records
The law is technology-neutral—it doesn’t prescribe specific tools or formats, only that records must be accurate, retrievable, and sufficient to enable tracing. Practices vary widely by company size, sector, and complexity:
Small producers/farms/artisanal operations — Often use paper-based records (logs, invoices, delivery notes) or simple Excel spreadsheets. Batch codes are manually recorded on documents/labels. This meets minimum legal requirements but can be error-prone and slow during audits/recalls.
Medium to large producers/processors — Typically use digital systems:
- ERP (Enterprise Resource Planning) software → Common platforms like SAP, Microsoft Dynamics, or food-industry-specific ones (e.g., JustFood ERP, Navision, or equivalents in Europe like CSB-System, Aptean Food & Beverage ERP). These integrate inventory, production, purchasing, and sales to automatically track lots/batches.
- Dedicated traceability modules → Often built into ERP or as add-ons, using barcodes (frequently GS1 standards for GTINs, batch numbers, etc.) for scanning and linking data.
- Specialized food safety/traceability software → Tools like FoodDocs, TraceX, Icicle, or Safefood 360, which handle lot tracking, supplier records, and recall simulations.
- Databases → SQL-based systems (e.g., custom or via ERP) for storing records; some use cloud platforms.
Many incorporate GS1 standards (global barcoding and data-sharing protocols) for interoperability across supply chains, especially exporters or those working with retailers (e.g., supermarkets requiring electronic data exchange via EDI or EPCIS).
In practice:
- Records include supplier names/addresses, product descriptions, quantities, dates, batch/lot numbers.
- Larger companies often go beyond the minimum with full internal traceability (e.g., tracking how ingredients are mixed in production) using barcoding/RFID for automation.
- Blockchain solutions are emerging but not yet widespread—current systems are mostly centralized databases/ERP, which work for compliance but lack the immutability and shared transparency of blockchain.
This setup ensures audits can verify chains quickly, but pain points (data silos, manual errors, slow multi-party tracing) are exactly what blockchain-anchored proposals aim to improve.
@Marcos_Moratrace What do you think is the differentiator and argument for a blockchain-based solution, instead of maintaining current practices (i.e., paper logs for small businesses, Excel spreadsheets or SQL databases for mid-size, ERP or food industry specific solutions for enterprises)?
What unique selling point you think blockchain has, to overcome the inertia of changing the status-quo?
To me it’s clear:
- you are engaged with this proposal, you take it seriously, and you are commited to making it work
- you are from the food industry, you know the regulations and practices, and pain points
- Mora Foods Ltd is an established company, which seems to be successful and have capability to expand to other products
- the proposal feels solid, the Milestones have a logic
- you intend to offer/sell this to companies, and have it actually used and have future growth, instead of just a new theoretical blockchain capability which never gets used
But the pain points I have are:
- it seems you don’t have a clear interested party, besides Mora Foods. So broad adoption is not guaranteed. Since our grants are non-diluting (we don’t get equity), our return-on-investment comes from expanding Rootstock ecosystem and usage with broader adoption.
- at $27k total this is not a cheap proposal. it errs on the high-risk/high-reward side. M1 starts at $10k. I feel like there’s an MVP at M2 ($18k) and a beta only on M3 ($23k), and a pilot on M4 ($27k).
- I understand if successful, this project would become a new commercial product from Mora Foods? While this is not impeditive, have in mind these grants are usually aimed at early-stage startups that are strugling to find initial capital to build their first product. Is Mora Foods commited to investing and sharing costs of this project?
Some suggestions that would have me more confident on supporting this proposal:
- trying to find other companies interested in using this product. Maybe getting one or two letters of intent, or soft commitments, or partners. A sounding on your own supply chain should give an idea on future adoption potential.
- trying to reduce the value of the proposal, securing a larger commitment from Mora Foods, keeping the proposal value under $20k.
Thank you for articulating these points, @ChronoTrigger (and in your earlier reply as well). You’ve clearly verbalized many of the same concerns I have.
I have first-hand experience working at a large consulting firm implementing blockchain–ERP pilots. In 2017, many of those initiatives stalled after the initial pilot phase. That said, the landscape does appear to be shifting. Traditional enterprises are once again exploring blockchain use cases (as evidenced by this proposal), and both the technology and leadership’s willingness to seriously experiment have matured significantly. As a result, we may finally see enterprise-grade implementations succeed.
Even so, there remains a real concern that enterprise blockchain initiatives risk being more hype than substance. Given that Mora Foods is a large, established company, there must be a clear and compelling ROI for Rootstock. As ChronoTrigger notes, Collective grants are generally intended to support early-stage startups. In this context, it feels important that Mora Foods meaningfully share in the investment costs.
At this point, I’m not convinced a grant is the right mechanism at all. If the Collective is serious about supporting an enterprise deployment of this nature, we should step back and have a broader discussion about whether a different funding structure would be more appropriate.
@Marcos_Moratrace thank you for bringing this proposal forward for consideration and discussion.
Hi @ChronoTrigger,
Thank you for taking the time to do the research and bring your queries to us. I hope that I have answered them below, as I tried to go straight to the point but at the same time I have added as much complementary information as I thought useful (apologies in advance if it seems that I am repeating myself sometimes, but it reads better at the end).
We are not making an argument to change the way internal MSME/ Artisans/ Small Farmers are recording their data. We are only proposing a way for the final consumers to access the final traceability data that is currently displayed on the label, along with extra information through a QR code secured by block-chain (extra information listed under Consumer Transparency, Market Access & Competitive Fairness, in the Description of the Project). 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.
Your research is fine as a general glimpse. It confirms that in practice the use of SQL databases, ERP, or food industry specific solutions for enterprises is something that only Medium to Large companies have implemented or can implement due to cost. We have factored that in the project, and we did exclude them from the target market figure (Target Users and Market Scope in the Description of the Project). This happens as they are the only ones that can afford them.
This project focuses on delivering product information to the final consumer. Not a single company in the sector will agree to digitalize and make available to a final consumer the internal HACCP information that is required by the authorities. Authorities do not require the digitalization of internal data as they know of the impact that the cost will have on their operations, or in the case of our target due to the lack of knowledge overall.
I would like to reiterate that we are not stating that there is a problem with the way things are being recorded, or that by doing in paper or excel, the legal requirements for this process are not met. Every single MSME/ Artisans/ Small Farmers licensed producer have adopted a way to correctly display the traceability batch number on the labels, and that is what the law requires. The thing is that only the local authorities can then access the traceability information on the internal company records, not the clients. That is all that it is, just a code that will be used in case of the implementation of a recall procedure, but it does not add anything more to the producer.
We are suggesting that our service will offer a product/batch data sheet that will be hashed in blockchain containing the same level of information as the label carries now and a lot more. It will never contain internal data such as production quantities, internal batch codes used during the production process, name of suppliers for ingredients, list of clients, or other information that is strategical (required to be recorded by law and only to be accessed externally by the national authorities).
If a company in the future sees the benefit of using the service for their internal processes, then a new off-chain architecture will need to be designed so that records are stored in their own wallet (some minor alterations to the on-chain as well).
We want to give the producer a chance to enrich the user experience by incorporating a QR code connected to the hashed data that was input by the web form. This will act a s bridge to cover the actual gap between our target market and the Medium and Large Companies.
This is not only about a service that will provide a tamper evident solution for traceability data, but it is about a solution that will finally allow a MSME/ Artisans/ Small Farmers to get more information to the final consumer in the same manner that Medium to Large Enterprises are doing it nowadays.
The main selling point for buyers is that Block-chain mitigates the risks that they find when dealing with MSME/ Artisans/ Small Farmers. It provides them with the certainty that the information on the records is tamper evident and was input by the producer. This new layer of security and enrichment of the data will have a positive impact on how the producer is perceived by buyers.
The main selling point for MSME/ Artisans/ Small Farmers is that they can connect with the final consumer and none of the information that they have connected to the QR code can be manipulated once it is hashed.
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.
We have designed a solution that does not require 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.
Thanks again,
Marcos
Hi @ChronoTrigger,
Thanks again, these are good points and I would like to give you our point of view on them. I have copied and pasted them to make it easier for me to respond:
- it seems you don’t have a clear interested party, besides Mora Foods. So broad adoption is not guaranteed. Since our grants are non-diluting (we don’t get equity), our return-on-investment comes from expanding Rootstock ecosystem and usage with broader adoption.
To clarify, The project has identified interested parties beyond Mora Foods. Companies in the pilot stages are producers and processors from two industry organizations we belong to, reflecting real operational interest. Their involvement reflects existing interest and operational alignment, rather than hypothetical demand. 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.
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.
In regard to the ROI: you are correct to point out on our intention to sell this service to other companies (developing such an infrastructure only for our use would not be feasible form a cost point of view). Under the proposed hybrid model, Mora Foods operates the on-chain interface and acts as the primary network participant, while thousands of downstream businesses consume the traceability service off-chain as part of their commercial operations (by downstream we are describing supplier and client businesses that consume the traceability service off-chain as part of their commercial operations). This structure reflects current industry constraints and reduces onboarding friction for non-technical users.
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.
**included under Information of the Project, in the Project Description: “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.”
-
at $27k total this is not a cheap proposal. it errs on the high-risk/high-reward side. M1 starts at $10k. I feel like there’s an MVP at M2 ($18k) and a beta only on M3 ($23k), and a pilot on M4 ($27k).
-
I understand if successful, this project would become a new commercial product from Mora Foods? While this is not impeditive, have in mind these grants are usually aimed at early-stage startups that are strugling to find initial capital to build their first product. Is Mora Foods commited to investing and sharing costs of this project?
The proposal may appear high-risk when viewed as a single $27k allocation, but the work is intentionally structured as a gated, incremental delivery rather than a single speculative bet. Each milestone produces independently usable outputs, and later stages are contingent on successful validation of earlier ones.
Milestone 1 is not exploratory; it establishes the core data model and on-chain integration necessary for the system to function. Subsequent milestones expand functionality and operational readiness, rather than transitioning from “idea” to “product.” In that sense, the MVP exists earlier in the roadmap than suggested.
While the system will be operated by Mora Foods, the grant-funded work is focused on building reusable infrastructure and integration patterns on Rootstock, not on subsidizing Mora Foods’ commercial product development. Mora Foods is contributing domain expertise, operational resources, and long-term maintenance, and is committed to deploying and operating the system beyond the grant period. Our funding: we are investing in the project as 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.
The grant is scoped to implementing and validating Rootstock integration for a traceability system that Mora Foods is committed to operating long term, rather than funding Mora Foods’ business or product development.
Some suggestions that would have me more confident on supporting this proposal:
-
trying to find other companies interested in using this product. Maybe getting one or two letters of intent, or soft commitments, or partners. A sounding on your own supply chain should give an idea on future adoption potential.
-
trying to reduce the value of the proposal, securing a larger commitment from Mora Foods, keeping the proposal value under $20k.
The suggestions are understood and address common risk signals in grant-funded product development. However, in this case they stem from evaluating the proposal as a multi-tenant product initiative, whereas the project is structured as an operator-led deployment model.
Under the proposed hybrid approach, Mora Foods is the sole on-chain operator and commercializes the service to the industry. As a result, early adoption does not depend on multiple independent companies committing to run the system directly, and letters of intent from third parties would not materially reduce execution risk at this stage. Adoption is driven by Mora Foods’ operational rollout rather than parallel onboarding of external operators.
Similarly, the proposal value reflects the full scope of Rootstock-facing integration required for a production deployment. Mora Foods’ commitment is expressed through non-grant contributions, including domain expertise, access to real operational data, client onboarding, off-chain infrastructure, and long-term operation and maintenance. Reducing the grant amount would require removing interdependent components rather than deferring optional features, which would limit the system’s ability to be deployed and evaluated in practice.
For our team, this initiative represents a first implementation of this technology and platform as a funding mechanism. Through the Traceability project, we aim to explore and validate the potential of blockchain-based infrastructure for future funding models, as well as for integrating existing community tools such as wallets, OpenTimestamps, and related solutions. Adopting this technology is a key step toward establishing the foundations needed to later launch DeFi-based payment products. At that stage, the involvement of the Collective will be essential to ensure alignment, adoption, and long-term sustainability.
The intent of the proposal is therefore not to validate market demand through multiple early adopters, but to establish and operate a concrete, real-world Rootstock use case whose on-chain usage scales with commercial activity after deployment.
That said, we are open to discussing milestone adjustments that preserve deployability while aligning with the program’s risk profile if needed.
Thanks,
Marcos
Hi @404Gov,
These are valid points, but they are not entirely applicable to our situation, as we are a small-sized SME rather than a large enterprise.
I understand how the confusion may have arisen, given the type of customers we have been supplying over the past several years. We have been able to serve these clients because our Food Safety Management System was designed to meet the standards of large enterprises and, importantly, is fully managed and supported in-house. 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. Our product range is both unique and highly niche, and for a company of our size, this level of capability is uncommon. However, maintaining this structure involves significant ongoing costs.
The project addresses a problem we have faced internally for some time: communication and the provision of tamper evident records. Before designing a solution, we consulted with numerous industry contacts to see whether a cost-effective service existed for a company of our size. Most were in the same position as us, and only high-end SMEs and leading companies had implemented this type of solutions—typically at a cost in the mid- to upper tens of thousands of euros for the first, and hundreds of thousands for the second.
It was then that we saw an opportunity: we have enough knowledge to design, test, implement, and bring this project to conclusion; we just need funding as it is something that we cannot fully fund it ourselves.
Having explored many paths, the reality is that there are not many platforms that are available for SME funding to develop this project. The technical knowledge of most of the people involved in grants for SMEs in the manufacturing sector is not enough, so these proposals are not even contemplated. The European IT related grants that are available to the manufacturing sector have been historically offered as support for trading online, and now for supporting the digitalization of the business (it covers software, training, and IT configuration). Nothing along the lines of what we are proposing to do and at very low amounts of investment (<5K).
There are grants designed for SMEs in the IT sector and are mostly for developers. The technical knowledge of those involved in the evaluation process would be like those of the Collective. Unfortunately, we do not fall into this category.
We are an early-stage startup in what it refers to technology. We are sharing in the investment costs as we are covering all the fixed costs and all the costs related to fund the part of the project that is not mentioned in the project during its first year of operation (including HR costs). As we mentioned to @ChronoTrigger previous queries: 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.
When we were steered to the Collective by an IOV former employee, he explained to us that this type of non DeFi project is something that falls under its mission as it aims at promoting the use of blockchain in the real world.
The project’s revenue model is based on operational service delivery within the supply chain (last step), ensuring sustained, non-speculative on-chain activity. Each additional participant generates recurring on-chain activity, directly contributing to Rootstock usage and ecosystem growth. The grant-funded work unlocks a scalable, non-speculative use case that persists and expands beyond the initial deployment.
He also mentioned that from his point of view, the fact that the project stems from a company that is operating is a plus, as it is able to fund the part of the project that is not IT related, and that is why we finally presented the project to you guys.
We appreciate your perspective and experience with earlier blockchain–ERP pilots. We are familiar with the type of projects you are referring to, and those were done by the biggest companies in both IT and the Grocery/ Shipping/ Pharma/ Retail industries. The investment was in the tens and hundreds of millions and while it would be amazing to try to compare to them (and thanks for even consider relating us to them), this is hardly the case. The only similarity at this point would be the use of block-chain. Most of these projects were developed as an in-house solution to their needs of tracking product more efficiently, to be used at each stage of the supply chain. And as you say, most did stalled and it was due to integration complexity or lack of real-world incentives. They were also mainly focused on testing technology feasibility, not full operational deployment
Our traceability project proposes a way for the final consumer to access the final traceability data that is currently displayed on the label, along with extra information through a QR code secured by block-chain (extra information listed under Consumer Transparency, Market Access & Competitive Fairness, in the Description of the Project). The service provides its users a direct line of communication to the final consumer, the chance to increase their sales by making their products more attractive to buyers by mitigating the risk of dealing with a MSME/ Artisans/ Small Farmers, and finally for those specialty producers with denomination of origin or specialty products, a tool to fight Food Fake. It is worth mentioning again that 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.
Finally, I would like to point out that this is not an exploratory pilot; it is a production deployment operated by Mora Foods, 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. As such, the risk profile is lower than typical exploratory pilots, and the project is structured to scale across a large, active network of participants.
Thanks again,
Marcos
Thanks for your detailed proposal and continuous engagement with the delegates, @Marcos_Moratrace. Really appreciated.
As other delegates have mentioned, the concept, direction and intention are clear and understandable and we appreciate your consideration into its integration with Rootstock.
However, we are doubtful that giving this size of a grant to this project will provide material impact to the Rootstock ecosystem and make meaningful impact in a reasonable time frame. The described value proposition is very vague and not convincing to us in terms of the return on investment perspective. Even if all of them make sense and reasonable for a grant, we are not certain that you have a right team to complete all the described milestones and deliverables, without a verifiable track record of the technical team to tackle this project.
A small clarification on the point @Kaf_StableLab made; the team background section hasn’t been fixed and still duplicated in the original post.
Hi @Tane,
Thanks for taking the time for revising our proposal. Appreciate the chance to expand on the topics that are not very clear. Again, we are learning the best way to show the project as we are new to this process.
We had fixed the double entry on the proposal file when it was picked by @Kaf_StableLab. We will be posting the amended proposal later with the explanations of the queries that we have been asked so far for a better read (which includes this amendment).
From an ROI perspective, the project is designed around a hybrid adoption model that reflects current industry constraints while maximizing long-term on-chain value for Rootstock.
In this model, Mora Foods operates 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.
The project delivers 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) (see below)
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.
Proof of Productive Behavior (PoPB)
· 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. Because PoPB is a framework that transforms production-based traceability anchored on-chain into verifiable economic reputation, such project will be able to source verifiable data. By immutably recording what is produced, when, under which operational standards, and who is responsible for each event, the system generates objective signals of actual productive behavior—such as consistency, compliance, persistence, and relational reputation—which can serve as a foundation for productive scoring. This approach enables uncollateralized financing, reduces information asymmetry for DeFi protocols and lenders, and establishes a legitimate operational bridge between the Real-World Economy (RWE) and decentralized financial infrastructure.
The implementation of this project serves as a strategic data feeder for a future Proof of Productive Behavior (PoPB) framework within the Rootstock Collective. By anchoring production-based traceability on-chain, this project generates the raw, immutable material required to build verifiable economic reputation.
Our ongoing technical evolution and established methodology ensure that as the project scales, we generate increasingly granular data for our users. Through a rigorous data curation and machine learning process, this information will mature into a formal Proof of Productive Behavior (PoPB). While our current phase and upcoming milestones represent an early-stage implementation, the traceability tools we are building today provide the essential foundation. Ultimately, this framework will deliver a robust Proof of Behavior model that provides tangible liquidity and risk-assessment benefits to DeFi projects across the Rootstock Collective.
Because PoPB protocols require high-fidelity inputs—recording what is produced, by whom, and under what standards—our project establishes the necessary ‘ground truth’ for productive scoring. This creates a long-term ROI for the Collective by:
· Unlocking New Markets: Enabling uncollateralized financing models that were previously impossible due to risk.
· Reducing Systemic Risk: Minimizing information asymmetry for DeFi protocols and lenders through objective behavioral signals (consistency, compliance, and persistence).
· Strengthening the Bridge: Solidifying Rootstock’s position as the premier operational bridge between the Real-World Economy (RWE) and decentralized financial infrastructure."
TEAM
Thank you for raising your concerns regarding the team and the ability to deliver the proposed milestones. Through continued interaction with members of the Collective, we better understand that much of the concern is centered on the technical track record. We would like to clarify how the project is structured to ensure successful real-world delivery.
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.
In summary, 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.
Thanks and best for 2026!,
Marcos
Thanks for the detailed response @Marcos_Moratrace.
We understand your assumption about potential impact and ROI generated by the introduction of the project, but still are not fully convinced that it’s worth giving a sizable grant at $27 that you asked. The idea of PoPB and the potential of being used for DeFi protocols, especially lending with non-collateralized assets/data are interesting, but not expected to be readily available. We are also skeptical of an assumption that users who are onboarded through this project will use other protocols on Rootstock. We would suggest that you design a proposal to hyper-focus on the key deliverables and lower the grant size further as @ChronoTrigger suggested.
We still see them as below, but as you will post an amended proposal, it wouldn’t matter much.
