Key Takeaways
- The ONDC Attribution Challenge: The decentralized nature of ONDC creates significant challenges for transparent and trustworthy marketing attribution, leading to potential data silos, disputes, and sophisticated ad fraud between Network Participants (NPs).
- Blockchain as the Solution: A dedicated Blockchain Attribution & Settlement Layer (BASL) can provide a single, immutable source of truth for all marketing and conversion events, eliminating discrepancies and building trust.
- Smart Contract Core: The protocol's heart is a set of smart contracts that log attribution events (impressions, clicks, conversions) and automatically execute settlements based on pre-agreed logic, using stablecoins or a future CBDC.
- Oracles are Critical: Decentralized oracles are essential for bridging the gap between off-chain ONDC events (like a successful delivery confirmation from a logistics partner) and on-chain smart contracts to trigger settlements.
- Privacy by Design: Hashing personally identifiable information (PII) and exploring Zero-Knowledge Proofs (ZKPs) are non-negotiable for ensuring compliance with India's DPDP Act 2023.
- Phased Rollout is Key: A successful implementation requires a multi-phase roadmap, starting with a Proof-of-Concept on a testnet, followed by a pilot program with select NPs, rigorous security audits, and finally, a mainnet launch with a clear governance model.
The Inevitable Trust Deficit: Marketing Attribution in a Decentralized ONDC
The Open Network for Digital Commerce (ONDC) is poised to revolutionize India's digital economy by unbundling e-commerce. It creates a level playing field where any seller can connect with any buyer through a network of interoperable applications. While this democratization is powerful, it introduces a complex, multi-stakeholder environment where the flow of data—especially marketing attribution data—becomes a critical point of failure or success.
In the traditional, centralized model, a single platform like Amazon or Flipkart controls the entire user journey and its associated data. In ONDC, the journey is fragmented across multiple, independent Network Participants (NPs):
- A user discovers a product on a Buyer App (e.g., Paytm).
- The product is listed by a Seller App (e.g., a custom app for a D2C brand).
- The transaction is processed by a Gateway.
- The delivery is handled by a Logistics Partner.
Now, consider a performance marketing campaign. The Buyer App runs a promotion. The Seller App pays a commission for every sale generated. How can the Seller App be 100% certain that the conversion data reported by the Buyer App is accurate and not inflated? How can the Buyer App prove its contribution in a multi-touch journey? This is the fundamental attribution challenge, and it's where traditional models break down, leading to disputes, revenue leakage, and a lack of trust that can stifle the network's growth.
This is where a protocol-level blockchain solution becomes not just an innovation, but a necessity. We propose a technical blueprint for a Blockchain Attribution & Settlement Layer (BASL), a shared, immutable ledger designed to bring radical transparency and automated execution to ONDC's marketing ecosystem by 2026.
A Protocol-Level Solution: The Blockchain Attribution & Settlement Layer (BASL)
The BASL is not another application; it's a foundational infrastructure layer that ONDC participants can plug into. Its design is based on four core principles:
- Immutability: Once an attribution event (like a click or a purchase) is recorded on the blockchain, it cannot be altered or deleted by any single party.
- Transparency: All authorized participants can view the same ledger of events, eliminating data silos and creating a shared, verifiable reality.
- Programmability: Smart contracts codify the attribution logic and settlement terms. "If a confirmed sale event occurs linked to Campaign X, automatically transfer Y% commission from Seller Z's wallet to Buyer App A's wallet."
- Atomicity: Settlements are atomic, meaning they either complete successfully in their entirety or fail completely, preventing partial payments or inconsistent states.
High-Level Architecture
The system comprises on-chain and off-chain components working in concert.
- ONDC Network: The existing ecosystem of Buyer Apps, Seller Apps, and Logistics Partners who generate the raw marketing and transaction events.
- BASL Ingestion Layer (Off-Chain): A set of APIs and SDKs that NPs integrate. This layer is responsible for receiving events, cryptographically signing them to prove origin, batching them to optimize costs, and submitting them to the blockchain.
- Blockchain Layer (On-Chain): The core distributed ledger (e.g., an Ethereum L2 or a permissioned chain) where the smart contracts reside. This layer is the single source of truth.
- Smart Contracts: Includes the
AttributionLogger contract to record events and the SettlementEngine contract to execute payments.
- Oracle Network: A decentralized service (like Chainlink) that securely feeds real-world, off-chain data (e.g., "delivery confirmed" status from a logistics partner's API) to the on-chain smart contracts, which is crucial for triggering settlement.

Technical Deep Dive: Building the ONDC BASL
Constructing this protocol requires careful architectural decisions, from the choice of blockchain to the specific logic within the smart contracts.
Choosing the Right Blockchain Stack
The choice of blockchain is a trade-off between decentralization, performance, and cost.
- Public L2 Rollups (e.g., Arbitrum, Optimism, Polygon zkEVM): This is the recommended approach. They inherit the security of Ethereum's mainnet while offering significantly higher throughput and lower transaction fees (gas), which is essential for handling a large volume of attribution events. They provide a high degree of decentralization and are interoperable with the broader DeFi ecosystem, enabling settlements in standard stablecoins like USDC or USDT.
- Permissioned/Consortium Chains (e.g., Hyperledger Fabric): This offers the highest performance and control. A consortium of major ONDC players could govern the network. However, it sacrifices public verifiability and decentralization, which might undermine the core goal of creating a trustless system.
- Application-Specific Chains (AppChains): A dedicated chain built using frameworks like the Cosmos SDK or Polygon CDK. This provides maximum customizability but requires more overhead in terms of validator set management and security.
For a network as public and diverse as ONDC, an Ethereum L2 Rollup presents the most balanced and future-proof choice.
Smart Contract Design for Attribution & Settlement
The logic of the BASL is encoded in Solidity (for EVM-compatible chains). We need at least two primary contracts.
1. The AttributionLogger Contract
This contract's sole purpose is to create an immutable log of marketing touchpoints.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
contract AttributionLogger {
// Event to be emitted for off-chain indexing and analytics
event EventLogged(
bytes32 indexed eventId,
uint256 timestamp,
bytes32 indexed userHash,
bytes32 indexed campaignId,
address indexed networkParticipant,
EventType eventType
);
enum EventType { IMPRESSION, CLICK, ADD_TO_CART, PURCHASE_INITIATED }
struct AttributionEvent {
uint256 timestamp;
bytes32 userHash; // Keccak256 hash of a unique user identifier
bytes32 campaignId;
address networkParticipant; // The address of the NP logging the event
EventType eventType;
}
// Mapping to store the events
mapping(bytes32 => AttributionEvent) public events;
// Only authorized NP addresses can log events
mapping(address => bool) public isAuthorizedParticipant;
address public owner;
modifier onlyAuthorized() {
require(isAuthorizedParticipant[msg.sender], "Not an authorized participant");
_;
}
constructor() {
owner = msg.sender;
}
function addParticipant(address _participant) external {
require(msg.sender == owner, "Only owner can add participants");
isAuthorizedParticipant[_participant] = true;
}
// Function called by NPs to log a new event
function logEvent(
bytes32 _userHash,
bytes32 _campaignId,
EventType _eventType
) external onlyAuthorized {
bytes32 eventId = keccak256(abi.encodePacked(block.timestamp, _userHash, _campaignId, msg.sender));
events[eventId] = AttributionEvent({
timestamp: block.timestamp,
userHash: _userHash,
campaignId: _campaignId,
networkParticipant: msg.sender,
eventType: _eventType
});
emit EventLogged(eventId, block.timestamp, _userHash, _campaignId, msg.sender, _eventType);
}
}
Key points in this contract:
userHash: We never store raw user data on-chain. A unique but anonymized identifier is hashed off-chain and the hash is stored, ensuring DPDP Act compliance.
onlyAuthorized modifier: Access control is critical. Only registered and verified NP wallet addresses can write data to the contract.
- Events (
EventLogged): Emitting events is a cheap way to make data available for off-chain services to listen to and build analytics dashboards without constantly querying the contract's state.

2. The SettlementEngine Contract
This contract holds the funds and the business logic for payouts. It would be called by an authorized party (or an Oracle) upon final confirmation of an order.
// Simplified example of a settlement contract
interface IAttributionLogger {
function events(bytes32 eventId) external view returns (/* ... */);
}
contract SettlementEngine {
// ... (owner, authorized parties)
// Maps a campaign ID to its attribution model and commission rate
struct CampaignRules {
address payable seller;
address payable buyerApp; // The affiliate/promoter
uint8 commissionBPS; // Commission in basis points (e.g., 500 = 5%)
// Potentially an enum for attribution model (e.g., LastClick, Linear)
}
mapping(bytes32 => CampaignRules) public campaignRules;
// Called by an oracle upon confirmed delivery
function triggerSettlement(bytes32 _purchaseEventId, bytes32[] calldata _touchpointEventIds) external {
// 1. Authenticate the caller (must be a trusted oracle)
// 2. Look up the purchase event in the AttributionLogger contract
// IAttributionLogger logger = IAttributionLogger(loggerAddress);
// AttributionLogger.AttributionEvent memory purchaseEvent = logger.events(_purchaseEventId);
// 3. Verify the touchpoint events and apply the attribution logic
// (e.g., find the last click before purchase)
// 4. Calculate the commission based on campaignRules
// uint256 commissionAmount = (purchaseValue * rules.commissionBPS) / 10000;
// 5. Transfer funds (e.g., using a stablecoin like USDC)
// IERC20(usdcAddress).transferFrom(rules.seller, rules.buyerApp, commissionAmount);
}
}
Data Flow and Oracle Integration: Bridging On-Chain and Off-Chain Worlds
A smart contract is blind to the outside world. It cannot natively call an API to check a delivery status. This is where oracles become the most critical piece of the infrastructure.
- Event Generation: A user clicks a promoted product on a Buyer App. The app's backend SDK creates a JSON payload with the event details, signs it with the NP's private key, and sends it to the BASL Ingestion API.
- Ingestion & Batching: The off-chain API gateway collects multiple events, verifies their signatures, and batches them. To save costs, it can construct a Merkle Tree of the event hashes and post only the single Merkle Root on-chain, drastically reducing data footprint.
- Order Fulfillment: The user completes the purchase. The ONDC transaction flows as normal, and a logistics partner is assigned.
- Oracle Trigger: The logistics partner's system marks the order as "Delivered" in their internal database. A decentralized oracle network, subscribed to this API endpoint, detects the status change.
- Settlement Execution: The oracle validates this data from multiple sources to ensure it's accurate, then makes a secure call to the
triggerSettlement function on the SettlementEngine smart contract, passing the relevant event IDs. The smart contract then executes the pre-defined payment logic trustlessly.

DevOps and Implementation Roadmap for a 2026 Launch
Deploying a protocol of this magnitude requires a careful, phased approach.
Phase 1 (Q1-Q2 2025): Protocol Design & Testnet PoC
- Form a working group with key ONDC stakeholders (Buyer Apps, Seller Apps, Gateways).
- Finalize the choice of L2 blockchain and the detailed smart contract architecture.
- Deploy v1 contracts to a public testnet (e.g., Sepolia).
- Develop basic SDKs for NPs to experiment with logging events.
Phase 2 (Q3-Q4 2025): Pilot Program & Oracle Integration
- Onboard 2-3 friendly Buyer and Seller Apps for a closed pilot.
- Build out the oracle integration with a major logistics partner's test environment.
- Focus on the data ingestion pipeline, ensuring it's scalable and secure.
- Refine attribution models based on real-world data from the pilot.
Phase 3 (Q1-Q2 2026): Scalability Hardening & Security Audits
- Conduct extensive load testing to simulate network-wide traffic.
- Perform gas optimization on all smart contract functions.
- Engage multiple top-tier blockchain security firms (e.g., Trail of Bits, OpenZeppelin) for comprehensive audits of all on-chain code. This is non-negotiable.
Phase 4 (Q3 2026): Mainnet Launch & Decentralized Governance
- Deploy the audited contracts to the chosen L2 mainnet.
- Establish a clear governance model, potentially a Decentralized Autonomous Organization (DAO), where token holders (representing ONDC stakeholders) can vote on protocol upgrades, such as adding new attribution models or changing oracle providers.
Frequently Asked Questions (FAQ)
Q1: Isn't blockchain too slow and expensive for high-volume ad events like impressions?
This is a valid concern with Layer 1 blockchains like Ethereum mainnet. However, by using Layer 2 Rollups, we can batch thousands of transactions into a single L1 settlement, bringing the cost per event down to fractions of a paisa. Furthermore, for low-value events like impressions, we can use off-chain data availability layers and only post Merkle Roots on-chain, making it economically viable.
Q2: How do you handle attribution model changes once the smart contract is deployed?
Smart contracts are immutable, but their architecture can be upgradeable. We would use a proxy pattern (like the UUPS or Transparent Upgradeable Proxy standard) where the logic contract can be swapped out for a new version following a successful governance vote. This allows the protocol to evolve without losing the state or address of the main contract.
Q3: How does this system comply with India's Digital Personal Data Protection (DPDP) Act?
Privacy is paramount. The protocol is designed to never store PII on the blockchain. All user-specific data (like a user ID or phone number) is hashed off-chain by the Network Participant's system before being sent to the protocol. The on-chain data is pseudonymous, linking events through these hashes without revealing the actual identity of the user, thus complying with data minimization and purpose limitation principles.
Q4: Does this replace existing analytics tools like Google Analytics or Mixpanel?
No, it complements them. The BASL is not a user-facing analytics dashboard. It is a foundational settlement and verification layer. NPs will still use their internal analytics tools for deep user behavior analysis. The BASL's role is to be the undisputed financial source of truth when it comes time to settle commissions and marketing fees between organizations.
Ready to Build the Future of Transparent Commerce on ONDC?
The transition to a decentralized digital marketplace requires a new paradigm of trust and verification. A Blockchain-Based Attribution & Settlement Layer is the cornerstone of that future, ensuring that all participants in the ONDC network can transact and collaborate with confidence.
Building such a robust, secure, and scalable protocol requires deep expertise in distributed systems, smart contract development, and enterprise-grade DevOps. The team at Induji Technologies has the experience and vision to architect and implement these next-generation solutions.
Request a Quote Today to discuss how we can help you design and build the foundational protocols that will power your ONDC strategy for 2026 and beyond.