Traceloop

Reuse First, Verified Recycle Last: Blockchain + AI Digital Product Passports for laptops with 3-party verified transfers, 3-way ledger reconciliation, and anti-greenwashing e-waste traceability.

Comment

Inspiration

Have you ever hesitated—or known someone who hesitated—to buy a used or refurbished laptop because its history was difficult to verify? That everyday trust gap led us to a bigger question: How can we keep electronics in use for longer if buyers cannot trust their history—and how can we trust sustainability claims if a device's end-of-life journey cannot be traced?

The environmental stakes are significant.

1. The Mid-Life Trust Gap — Broken Reuse

When buyers cannot reliably verify a laptop's ownership history, hardware changes, and inspection records, they may hesitate to purchase refurbished devices. This undermines reuse and can contribute to premature replacement and additional manufacturing demand. Foxway's assessment of 51 laptop models estimated that production itself accounts for approximately 80% of a new laptop's modelled carbon footprint. Source: Foxway's Handprint Report 2023.

2. The End-of-Life Traceability Gap — Unverified Recycling

The problem does not end when a laptop can no longer be reused. According to the ITU and UNITAR's Global E-waste Monitor 2024, the world generated 62 million tonnes of e-waste in 2022, yet only 22.3% was documented as formally collected and environmentally soundly recycled. Poorly managed e-waste can expose people and the environment to hazardous substances. Source: ITU.

These two challenges shaped our central insight: electronics circularity needs trust throughout a device's lifecycle, not just at resale or at the point of recycling.

That inspired us to build TraceLoop around one principle: Reuse First, Verified Recycle Last. We connect a device's lifecycle history with verification records, accountable ownership transfers, and evidence-backed end-of-life handling—helping make reuse more trustworthy and sustainability claims easier to scrutinize.

What it does

TraceLoop is a full-lifecycle Digital Product Passport (DPP) platform for circular electronics. It connects a laptop's public identity (TL-{BRAND}-{24-HEX}) to its recorded lifecycle history, helping buyers assess refurbished devices, authorized verifiers maintain configuration integrity, and recyclers document accountable end-of-life handoffs.

1. Persistent Digital Product Passports — Reuse First

Every registered laptop receives a persistent, serial-independent public Passport ID linked to its lifecycle record.

Anyone can look up a public passport (or explore our pre-configured TestNet demo passport directly from the landing page) to inspect the device's recorded state, current configuration, verification stamp status, and confirmed lifecycle events. Sensitive hardware serial numbers, internal database UUIDs, and private KYC/invoice files remain strictly outside the public view.

Instead of relying solely on a seller's static PDF invoice or an unverified screenshot, buyers can examine the reconciled lifecycle history before making a reuse decision.

2. Three-Party Verified Transfer Handshake & Re-Verification at each transfer and hardware change

TraceLoop coordinates a three-party verified transfer workflow. The seller initiates the transfer, the intended recipient explicitly accepts, and the assigned verifier completes the workflow. FastAPI enforces recipient acceptance and verifier assignment, while the smart contract requires an authorized verifier-role signer and a valid stamp to execute the final lifecycle transition. The on-chain transition records the handoff, but does not independently prove that a physical inspection occurred.

A valid verifier-issued stamp is required to initiate a transfer, and stamps older than seven days are rejected. Whenever an ownership transfer completes—or whenever an owner declares a mid-life hardware upgrade (declare_hardware_change, such as a RAM or SSD replacement)—the backend automatically invalidates the existing stamp (stamp_valid = False), requiring fresh service-centre re-verification before the next resale.

3. Guardrailed AI Passport Intelligence & Lifecycle Anomaly Triage

TraceLoop pairs deterministic backend rules with AI explainable implementation across two distinct surfaces, backed by a deterministic fallback when AI is unconfigured:

  • Consumer Passport Intelligence: Converts pre-reconciled lifecycle facts and four field-level reconciliation checks, including two cryptographic commitment comparisons into plain-English passport summaries so buyers don't need to read raw blockchain logs.

  • Admin side Lifecycle Anomaly Triage: The Admin Console evaluates eight deterministic review signals across confirmed V2 records—including transfer velocity flags, repeated hardware changes (3+ in 30 days), short-interval verification stamp clusters (3+ in 24 hours), stalled or uncertain chain submissions, stamp-versus-hardware timestamp drift, dispute-state mismatches, and registration reconciliation issues.

Strict AI Safety Boundary: Neither AI engine can read raw serials/PII, alter lifecycle states, or authorize transactions. Both pass sanitized JSON through post-generation regex validators that block unverified physical claims (e.g., "guaranteed authentic") or premature accusations of fraud.

4. On-Chain Enforcement & Three-Way Lifecycle Reconciliation

TraceLoopLedger (deployed on Algorand TestNet, App ID 771258340) enforces legal state transitions using on-chain Box storage (BoxMap) and emits ARC-28 events for device registration, verification, ownership transfers, hardware changes, dispute freezes/resolutions, recycling, and export.

Rather than blindly trusting the off-chain database, TraceLoop's reconciliation engine (PassportFactsService) independently cross-checks three sources on every passport lookup:

  • Algod: Live on-chain Box state and cryptographic commitments (owner_hash, config_hash, stamp_valid).
  • Algorand Indexer: Independent historical ARC-28 transaction logs decoded from chain.
  • PostgreSQL: Application workflow records and the subscriber event mirror.

The service explicitly surfaces MATCH, CONFLICT, PENDING_SYNC, CHAIN_ONLY, or OFFCHAIN_ONLY states surfaces detectable discrepancies, missing mirrored events, and incomplete or delayed source results..

5. Accountable End-of-Life Handling, Eco Points & Anti-Greenwashing Metrics

When a laptop reaches end of life, TraceLoop supports a recorded handoff to a platform-approved recycler. The backend checks the approved recycler record, current ownership, and acknowledged receipt (RECEIVED) before requesting recycling completion on-chain. The contract restricts mark_recycled to a whitelisted recycler-role signer and a device in TRANSFERRED state. These controls create an auditable record of the reported handoff, but do not independently prove physical treatment or safe material recovery.

Upon confirmed recycling, TraceLoop distributes Eco Points across the unique participants recorded in the device's completed transfer history and the recycler—rewarding everyone who kept the laptop in the verified loop.

Deliberate Anti-Greenwashing Design (COUNTS_ONLY): The public Climate & Circularity feed reports confirmed lifecycle activity from configured virtual-device passports and links to Lora TestNet Explorer records. Admin Analytics combines operational database metrics with mirrored on-chain event counts.

Why it matters

TraceLoop connects device identity, 3-party verified reuse workflows, 3-way auditable ledger reconciliation, and guardrailed AI anomaly triage in one cohesive ecosystem.

By clearly separating what the blockchain and database can prove from physical events that require human inspection or hardware telemetry, TraceLoop makes second-hand electronics safer to reuse and sustainability claims harder to greenwash.

How we built it

We built TraceLoop as a full-stack Digital Product Passport platform combining a React frontend, a role-controlled FastAPI backend, PostgreSQL records, an Algorand smart contract, and deterministic lifecycle reconciliation. Our engineering principle is to use blockchain to enforce key lifecycle transitions, the backend to manage people, permissions, and evidence, and AI to explain precomputed information—not decide whether it is true.

1. Frontend and Application Backend

The frontend uses React 18, Vite, and React Router, with workspaces for buyers, resellers, authorized verifiers, recyclers, and administrators, alongside public passport lookup and a TestNet circularity feed.

The backend uses Python, FastAPI, SQLAlchemy, and PostgreSQL. It manages OTP-based authentication with JWT sessions, role-based access control, device registration, verifier assignment, recipient acceptance, evidence records, disputes, recycling workflows, notifications, and Eco Points.

Evidence files are uploaded through the backend to configured Supabase Storage intended for private KYC, purchase-proof, and role-authorization documents. The system records SHA-256 digests and file sizes and rechecks stored evidence during protected credential checks. A matching digest establishes file integrity against the stored record; it does not independently prove that a document is authentic at source.

For ledger operations, the backend persists attempt state and confirmation metadata to support recovery from uncertain outcomes. Transfer and recycling-completion paths use conditional database updates to claim submissions and prevent competing requests from both submitting the same operation. Registration and verification have their own pending and reconciliation states. These are operation-specific recovery mechanisms; not every mutation uses the same protocol, and uncertain chain outcomes require reconciliation rather than blind retries.

2. Smart Contract and Lifecycle Enforcement

We implemented TraceLoopLedger using Algorand's Python smart-contract framework (algopy / PuyaPy), compiled to TEAL and supplied with ARC-56/ARC-4 contract artifacts and an AtomicTransactionComposer client. The configured demonstration uses Algorand TestNet, Application ID 771258340.

Per-device lifecycle records are maintained in on-chain Box storage (BoxMap). The contract enforces critical transition rules: transfers require a VERIFIED device and a valid stamp; hardware-change declarations invalidate the on-chain stamp; dispute resolution forces re-verification; and terminal RECYCLED and EXPORTED states block further lifecycle mutations.

The transfer workflow coordinates three roles: the seller initiates, the intended recipient explicitly accepts, and the assigned verifier completes the workflow. Recipient acceptance and individual verifier assignment are enforced in FastAPI; the contract enforces the final authorized transition. Verifier and recycler transactions use shared role-level custodial signers, so the on-chain sender identifies the role account rather than independently identifying the individual technician or facility.

For existing contract deployments, the API uses a state-aware effective-stamp policy after transfer and terminal transitions. This distinguishes whether a stamp is active for a new transfer from a raw bit the older on-chain contract may retain. The backend policy does not itself change the stored on-chain bit.

3. Event Indexing and Three-Source Reconciliation

Raw blockchain transactions alone do not make a readable device passport. We built an ARC-28 event decoder and background subscriber that paginates Algorand Indexer results and mirrors recognized, confirmed lifecycle events into PostgreSQL.

Each mirrored event receives a deterministic UUID derived from its transaction ID and log index. The subscriber uses a file-based round watermark with atomic replacement, advances it only after the searched range has been completely processed, and retries incomplete ranges rather than silently advancing beyond known failures.

When Passport Intelligence is requested, PassportFactsService compares the current Algod state, historical Indexer events, and local application/event-mirror records. It performs field-level comparisons, records source completeness, and returns statuses such as MATCH, CONFLICT, PENDING_SYNC, CHAIN_ONLY, OFFCHAIN_ONLY, PARTIAL, and SOURCE_UNAVAILABLE.

The comparison uses cryptographic hashes for ownership and configuration commitments, direct state comparison for lifecycle labels, and state-aware semantics for the effective transfer-stamp status. This lets the UI distinguish a detected conflict from missing data or an Indexer that is still catching up.

4. Passport Intelligence and Lifecycle Anomaly Triage

We built two AI-assisted workflows using the Google Gemini API.

Passport Intelligence assembles deterministic lifecycle facts and reconciliation results first, then uses PassportExplanationService to generate a readable status report. The model cannot query the database or determine the reconciliation status. If AI is unavailable or its output fails validation, the service returns a deterministic fallback.

Lifecycle Anomaly Triage uses LifecycleAnomalyService to evaluate eight categories of deterministic review findings. The Admin Console presents the resulting signals and supporting record references, while an optional AI-generated brief summarizes the selected findings and suggests review checks.

Both workflows use constrained, allow-listed model inputs and validate generated output against specific checks. These are guardrails, not proof that a model can never make a mistake. AI is advisory and never approves users, authorizes transfers, changes lifecycle state, or independently establishes fraud.

5. Privacy, Evidence, and Circularity Reporting

New V2 devices use a dual-identity scheme: a private internal UUID for database relationships and a serial-independent public Passport ID (TL-{BRAND}-{24-HEX}) for on-chain keys and public lookup. Raw serial numbers and owner identities are kept off-chain; hashes are used where the ledger workflow requires commitments.

The public passport uses an allow-list for visible configuration fields and excludes raw serial numbers, internal database UUIDs, and private KYC or invoice files. The separate Passport Intelligence response assembles public-safe facts without passing raw serials, internal user IDs, transaction references, or arbitrary metadata to the model.

The recycling workflow requires platform-approved recycler with approved authorization evidence, recorded ownership by the recycler, and a receipt acknowledged as RECEIVED before submitting the terminal transition. Eco Points are attempted as a separate best-effort operation after recycling succeeds.

The public Climate & Circularity feed reports unique confirmed transaction references from configured virtual-device passports and links to Lora. Admin Analytics offers broader operational counts from PostgreSQL and event-mirror records, plus recent on-chain event links to Lora and Pera Explorer.

Challenges we ran into

1. Keeping Blockchain and Database Records Consistent

One of our biggest challenges was keeping the on-chain device state, indexed blockchain history, and PostgreSQL records consistent throughout a device's lifecycle. A blockchain transaction can succeed even when the backend encounters a timeout or fails to persist its confirmation. Blindly retrying such operations could create duplicate or conflicting actions.

We designed recovery mechanisms around persisted submission states, transaction-confirmation metadata, conditional database updates in critical workflows, and explicit reconciliation outcomes. Instead of treating every missing response as a failed transaction, TraceLoop distinguishes confirmed, uncertain, conflicting, and incomplete states so uncertain operations can be investigated before retrying.

2. Maintaining Trust Across Ownership Transfers and Hardware Changes

A simple ownership-transfer button would not solve the trust problem behind TraceLoop. We needed to coordinate seller initiation, explicit recipient acceptance, and completion by an assigned verifier, while ensuring the final lifecycle transition followed the smart contract's rules.

We separated responsibilities between FastAPI and Blockchain Layer: the backend manages buyer acceptance, verifier assignment, permissions, and workflow status, while the contract enforces the final authorized transition and records it on-chain.

We also had to handle legitimate hardware upgrades without allowing outdated verification to remain valid for a future transfer. Declaring a RAM or SSD change invalidates the previous verification stamp and requires re-verification before the device can return to the verified-transfer workflow. Keeping the effective stamp status consistent across the backend, contract, and public passport required particular care, especially when an older contract deployment retained a raw stamp flag after a lifecycle transition.

3. Making AI Useful Without Letting It Decide What Is True

Lifecycle records can contain missing events, delayed indexing, conflicting states, and claims that software alone cannot establish. Sending raw logs directly to a language model could expose sensitive information or produce explanations that sound more certain than the underlying evidence.

We therefore placed deterministic reconciliation and anomaly rules before the AI layer. Passport Intelligence receives structured, allow-listed lifecycle facts, while Lifecycle Anomaly Triage receives precomputed review findings. AI helps explain what needs attention, but it cannot authorize transactions, change device state, or independently establish fraud. Deterministic fallbacks also keep the core explanation workflows available when the AI service is unavailable or unconfigured.

Accomplishments that we're proud of

1. Making Blockchain Practical Through Abstraction

We are proud of bringing blockchain into a real-world electronics lifecycle workflow without making users interact directly with its underlying complexity. TraceLoop puts familiar actions—device registration, ownership transfers, verification, and recycling—at the centre, while Blockchain handles critical lifecycle transitions and provides an auditable record.

Our aim was not to use blockchain simply as a technology showcase, but to make its capabilities useful within an everyday device-lifecycle experience.

2. Balancing Transparency with Privacy

A trustworthy Digital Product Passport should make relevant lifecycle information accessible without exposing sensitive personal or device data. TraceLoop uses public device identifiers to connect lifecycle records while keeping raw hardware serial numbers, internal database identifiers, and private KYC and purchase-proof documents outside the public passport.

We also go beyond displaying records: by comparing blockchain state, indexed history, and application records, TraceLoop can surface discrepancies and incomplete synchronization instead of asking users to blindly trust a single source.

3. Building Trust into the Entire Device Lifecycle

We wanted trust to be built into how devices move through the circular economy, rather than added as a label after the fact. TraceLoop coordinates seller initiation, recipient acceptance, and assigned-verifier completion through a three-party transfer workflow anchored by an on-chain state transition. Hardware changes invalidate previous verification, requiring re-verification before the device can proceed through a subsequent transfer.

The same principle extends to end of life, where the platform records an authorized recycler workflow and acknowledged receipt before requesting the terminal recycling transition. Together, these mechanisms connect trust across reuse, ownership changes, verification, and recycling.

4. Taking a Student-Built Idea Beyond the Screen

We are proud to have taken TraceLoop beyond our own assumptions by discussing its real-world relevance with Poornam EcoVision Foundation, a Pune-based environmental organization involved in waste management, including e-waste collection and recycling initiatives.

In an exploratory conversation with its CEO, we received encouraging feedback that the idea could be useful in real-world e-waste management. The discussion also highlighted an important adoption challenge: implementing such infrastructure at scale may require government support and coordination across the wider ecosystem.

For us, this was a valuable early signal that the problem we are addressing matters beyond a student-built prototype. It was an idea-validation conversation—not a formal partnership, pilot, or deployment—and it helped us think more seriously about the institutional support and stakeholder participation needed to take TraceLoop further.

Ultimately, we are proud to have brought these ideas together in a working prototype.

What we learned

1. Blockchain Is Only Useful When It Solves a Real Workflow Problem

We learned that putting records on a blockchain is not enough. The real value comes from connecting enforceable lifecycle transitions to practical workflows that people can use without understanding the underlying blockchain. In TraceLoop, that means combining seller initiation, recipient acceptance, and assigned-verifier completion with an auditable on-chain transition.

2. Transparency and Privacy Must Work Together

A device passport needs to expose enough information for someone to assess a device without revealing the owner's identity, raw serial number, or private documents. We learned to separate public lifecycle information from private evidence and to distinguish a record being available from that record being trustworthy.

3. Trust Requires Evidence Across the Entire Lifecycle

A valid inspection record can become outdated after a hardware change, and a recorded recycling event does not independently prove what happened to the physical device. We learned that lifecycle trust requires more than a one-time certificate: it needs controlled transfers, re-verification, evidence-backed handoffs, and reconciliation that surfaces discrepancies instead of silently assuming everything matches.

4. Understanding the Difference Between Building and Adoption

An exploratory conversation with Poornam EcoVision Foundation, an organization working in environmental protection and waste management, gave us encouraging early feedback on the potential relevance of TraceLoop to real-world e-waste management.

The conversation also highlighted a broader lesson: building a working technical solution is different from getting an entire ecosystem to adopt it. While a focused pilot can help validate the product with refurbishers, service centres, and recyclers, wider adoption may require coordination among industry participants and government support.

This helped us think beyond technical feasibility towards the practical relationships and processes needed to bring TraceLoop into real-world use. The conversation was early feedback on our idea, rather than a formal partnership or deployed pilot.

What's next for Traceloop

1. Validate the Complete Lifecycle with Real Participants

Our next step is to explore a small, proposed pilot involving a organization or refurbisher or authorized service centre and an authorized recycler. We want to understand whether the passport provides useful information at purchase, whether re-verification fits existing refurbishment workflows, and whether the recorded handoff and receipt process works operationally. This is a planned validation step, not an existing partnership or deployment.

2. Validate the Evidence Behind End-of-Life Claims

We want to investigate how recycler authorization, physical receipt, material recovery, and completion records can be supported by stronger evidence and appropriate external verification. This includes exploring suitable integrations with relevant registries and industry participants, subject to access, permissions, and operational feasibility.

3. Move from Activity Counts to Measured Environmental Impact

The current prototype deliberately reports observed lifecycle activity without assigning unverified carbon savings or e-waste mass to each transaction. Our next step is to develop a defensible impact methodology using measured device mass, relevant lifecycle-assessment data, and a realistic counterfactual for whether reuse actually avoids a replacement purchase. Only then should TraceLoop report quantified CO₂e benefits or physical e-waste diverted.

4. Build Toward Shared Circular Electronics Infrastructure

In the longer term, we want TraceLoop to support collaboration among buyers, refurbishers, service centres, recyclers, and other relevant stakeholders through a shared, evidence-linked device history. Achieving this will require validating the model with real participants, establishing appropriate trust and governance arrangements, and understanding where institutional or government support is necessary.

Our direction remains the same: Reuse First, Verified Recycle Last—make electronics easier to trust while they remain useful, and their reported end-of-life journey easier to scrutinize when they do not.

Built With

Share this project:

Updates

Submission history