Continuum

The justice system, investigative work, and forensics all share a fundamental requirement: trust in evidence. Whether it’s a seized phone, a photo, a forensic export, or a confidential document, the integrity of that evidence, and the transparency of its custody, can determine the outcome of a case.

Today, this trust depends heavily on centralized systems, private servers, and manual procedures. Evidence can be accessed without oversight. Chain-of-custody logs can be lost, altered, or challenged. Sharing evidence between agencies, experts, or jurisdictions often means unsecured emails, USB keys, or blind trust.

Our project introduces a better model: a decentralized chain of custody for evidences, where integrity, access, and ownership are enforced cryptographically. The application allows investigators, analysts, auditors, and legal teams to anchor a logical representation of an evidence on-chain (or the evidence itself if it's digital).

The data attached to an evidence (all its reports, documents, photos, etc.) are encrypted and protected on-chain. I am using Lit Protocol to ensure a strict access control to the decryption of a file. Even the application operator would not have access to the data. Only the wallet which has the current custody can decrypt data and this permission updates automatically as custody changes. Also, the encrypted files are stored on Lighthouse to ensure a decentralization and ensure access to evidence files no matter what.

The application enforce accountability when transferring custody. When an evidence is passed to another person, expert, or department, the transfer must be accepted, and every step is logged in a transparent, immutable custody timeline (along with information on the transfer itself like its purpose). The recipient must then accept custody, updates the evidence dataset (adding expertise report, for example) and return the custody or pass it to someone else. Everything transparent and immutable while preserving the absolute privacy of its content.

When creating a case (which is a logical grouping of evidences essentially), we define the access control for it. We can add participants in a case (other wallet addresses than the submitter) and defines their access level (OWNER which could remove members, add members and update the settings of the case, EDITOR which can do everything relating evidences but do not control the case accesses and VIEWER which can only have a read access to the case and its evidence.

I also analyzed and prepared the custody policies which would give more control when transferring an evidence, like with an expected return timestamp which, depending on the transfer policy chosen, could automatically revert custody at the deadline if not return prior. Also, when adding an evidence to control the conditions for the decryption, for now only the custodian can decrypt, but I wanted to add in mode in which the original submitter can also retain decryption access. Sadly those policy settings are just work in progress, I focused on a simple prototype to display the concept.

The smart contracts I did also as preparations for a verification process. I wanted to implement a verified level for a wallet address. The core concept around this feature was to allow organizations to register and add its members (invite them). The organization itself would pass through a verification process (checking its an existing company with the proper registrations and all). We could give them a verified level that they could then give to their members. This could then become a configuration used when anchoring evidence, for example, that we required a VERIFIED_L2 level to handle this evidence. But for the scope of the proof of concept, it was not our goal to implement the organizations. Anyways, the whole application works without it, its just a nice thing to add for credibility for future development and also to help onboard law related organizations into the application (which is out of scope for the hackathon).

There was also plans to integrate the concept of "revisions" for the evidence. But it was a bit complicated to integrate for the demo. Essentially, it does a new "version" for each custodian of an evidence. When you anchor an evidence, it does a manifest hash of everything that happened to the evidence up to that point. So to keep immutable history, the idea is to produce revisions for each custodian and its actions. This will be implemented post-hackathon.

The result is a verifiable chain-of-custody ledger that cannot be forged and a privacy-preserving evidence vault that respects both security and due process.

The application workflow goes as follows:

1. You signin with your wallet (SIWE)
2. Application detects you are a new user and asks you to fill the profile information (firstname, lastname, email and primary role). It then tries to reach ENS to gather the avatar and wallet name if applicable and download the image locally to avoid CSP errors. Else, it will create an identicon for the wallet stored locally too.
3. Once you completed the profile, you are prompt to verify the email address. Just follow the link in the emails to confirm. The idea is we could keep the user updated with notifications through emails (when the user has to accept a custody for example), also helps for authenticity.
4. The last step for your profile is to anchor it on-chain by calling the SubmitterRegistry contract. For now, the user pays for gas. But in a later version I would do a relay server which pays for the transactions and then having multiple payment plans for users of the application. For the demo tho, all actions are paid by the user.
5. Then you have access to the application. From there, you can create a new case and then add members and evidences to it.
6. You can then add files to an evidence and anchor it when ready (again posting it on-chain calling the EvidenceRegistry contract).
7. Once anchored, you can transfer custody (the demo ends here).

The backend of the application is in PHP (yeah I'm old-school, but I also try to show around that PHP is viable to blockchain dev, I did couple libraries which helps implement some blockchain features like ENS profile fetching, Moralis and now Lighthouse for this hackathon).

I created a new PHP library for Lighthouse during the hackathon which I took time to properly do. It's nicely refactored, has good documentation, score of A for code quality, unit testing (98% coverage), integration test and a working GitHub CI workflow that does the testing automatically. I released it on Packagist (the dependency manager of PHP through Composer) and I am using it in this project (https://github.com/ophelios-studio/php-lighthouse-storage). I don't think I am eligible for Lighthouse price pool, but I will still submit to them so they can see I implemented their solution in the application.

The front-end is pure HTML, CSS and VanillaJS. I am using Tabler.io as my visual template. I did heavy modifications tho to have a completely unique login screen. For the contract interactions I am using Viem. The HTML is rendered on the backend with Latte. For the backend I am using a PHP Framework Zephyrus (which I am the creator of).

I did my smart contracts with Solidity and HardHat 3 project structure with unit testing. It was a great experience to try the new HardHat. It was very simple to setup and intuitive once you read the documentation. Since I had more contracts this time and more complexity than what I do normally, I decided to try a proper contract project manager and it was a flawless experience overall.

I used Lit Protocol to encrypt the evidences files. Each upload is properly encrypted by Lit following a strict condition to decrypt (the custodian is the only one that can decrypt). I used v7 for the demo, because I had issues implementing v8 in the browser somehow and I was taking more time than what I could afford for this part of the project. But in the future, I will surely check to implement v8. This is the tech-stack that took me the most time ... It is by concept pretty simple, but the documentation was kinda hard to come by. Parts here and there and generic bugs like there was something missing in my JSON payload to Lit, but no real indication on what. I had to resort to ask in Discord and user @spacesai1or helped me a great deal on this issue and I was able to progress, but before that I lost a lot of hours on this.

I don't think I qualify for the Lit prize pool because my project has anything to do with AI Agent or DeFi, but I choose this technology not because of the prize attached to it, but because of its real encryption features which are amazing an exactly what I wanted to ensure security of the evidences. Just like Lighthouse, I think I will submit just to show them a usage of Lit in a concrete project.

Overall the project went well. My only issue was the time ... I know we had couple weeks to dev, but with my fulltime job as a teacher and my 1y old baby at home, it was quite the challenge to gather enough time to progress properly. Having more time I would have surely implemented everything I had envisioned, but I am still very happy of the milestone I got with the time I was able to invest in.

I focused on creating an application I was motivated to work on with a mix of great technologies, not for the prize pool, but because they are great tech that I wanted to use in my project.