Primary product ownership and full-stack delivery
Auditor Portfolio
A professional portfolio that brings a Web3 security auditor’s findings, achievements, earnings, and rankings from multiple platforms into one public profile.
cergyk public portfolio1 / 3
Product flow
From fragmented competition data to a trusted public profile
The product brought records from several security platforms into one profile and used direct auditor feedback to keep the data useful and accurate.
01
External platforms
Competition history, findings, achievements, earnings, and rankings.
02
Ingestion and normalization
Collected differently structured records and converted them into consistent data.
03
Unified auditor record
Connected activity across platforms into one professional history.
04
Public portfolio
Presented findings, achievements, earnings, and rankings in one profile.
05
Feedback and support
Auditors reported gaps directly, creating a loop for correcting ingestion and display issues.
The user problem
Web3 security auditors often compete across several audit and security-contest platforms. Their findings, earnings, achievements, and ranking histories were fragmented, leaving no single place to present a complete professional record.
My role and context
A colleague had begun the initial work before I took over and became the product’s primary owner inside Sherlock. I was responsible for keeping it accurate, improving the experience, and supporting the auditors who depended on it.
The product operated with a high degree of autonomy inside a lean engineering team. I worked across product decisions, data, backend services, and frontend delivery rather than treating implementation as a handoff between separate functions.
What I owned
- Collected and normalized competition history from leading Web3 security platforms.
- Built backend-to-frontend flows that turned fragmented records into unified auditor profiles.
- Shaped the interface and product experience around how auditors presented their work.
- Contacted auditors to encourage adoption and understand why some were not actively using the product.
- Handled support directly and investigated missing or incorrect contest data across ingestion and display.
Product and technical scope
Each profile brought together achievements, vulnerability findings and descriptions, earnings across platforms, and cross-platform leaderboard positions. Building that view required consistent records from sources with different structures and assumptions.
I worked across the ingestion and normalization layer, backend-to-frontend data flows, and the public interface. When data was missing or incorrect, I traced the issue across those boundaries rather than treating it as only a frontend problem.
Working directly with users
I contacted auditors to understand what stopped them from using their profiles and used those conversations to identify improvements. Support happened directly, usually through Discord rather than a formal ticket queue.
Auditors also contacted me when contests, achievements, or other information were incomplete. Those reports became a direct feedback loop for improving data accuracy and the product experience.
Observable outcome
Profiles were created automatically for Sherlock competitors, so the total number of profiles was not a meaningful adoption measure. The stronger signal was voluntary use: dozens of auditors publicly linked their Sherlock profile as their main professional portfolio.
Auditors relied on the profiles enough to report missing or incorrect information directly, showing that accuracy mattered to how they presented their professional work.