gem search - Moses Yebei

The Problem

Researchers and traders need a quick, local way to evaluate Solana memecoins—identifying bundle or linked‑wallet patterns, developer ownership, and historical launch performance—without trusting a remote service or manually parsing on‑chain data.

What This Does

gem-search is a local, end‑to‑end tool that scans a Solana contract address, produces a ranked score, and visualizes linked wallets and launch cohorts. The web UI (static/index.html + static/app.js) shows the scan results and the spider’s provenance graph. The background worker (launch/worker.mjs) performs the heavy on‑chain queries and writes the findings to a local SQLite database. The Chrome extension (extension/background.js, extension/content.js) injects the spider UI into social‑media feeds, turning any post into an interactive research card.

How It Is Wired

Entry Point – app.py

app.py starts a Flask server (app = Flask(__name__)).
On /scan, it calls scan_contract(address) defined in app.py which orchestrates the scan workflow.
scan_contract imports launch/worker.mjs via subprocess.run(['node', 'launch/worker.mjs', address]).
The worker emits JSON to stdout; app.py parses it, stores it in db.sqlite, and returns the score and links.

Launch Layer – launch/*.mjs

worker.mjs loads the Solana RPC client (via @solana/web3.js), pulls transaction history, and calls helper functions in launch/transport.mjs.
transport.mjs formats the raw data into the DATA_FORMAT.md schema.
guard.mjs validates addresses and checks against a whitelist; check-provider.mjs resolves the RPC provider.

Extension Layer – extension/*.js

background.js listens for chrome.runtime.onMessage from content.js.
content.js scans the DOM for Solana addresses, sends them to background.js, which forwards them to the local Flask API.
The response is rendered into the popup UI (popup.html + popup.js).

Database & Persistence All scan results are stored in db.sqlite via SQLAlchemy models defined in app.py. The tests/ folder contains unit tests for app.py, launch/*.mjs, and the extension.

How To Use It

# Clone
git clone https://github.com/moses-y/gem-search
cd gem-search

# Install dependencies
pip install -r requirements.txt          # Python back‑end
npm install                                # JavaScript front‑end & extension

# Start the local server
python app.py

# Load the Chrome extension
  1. Open chrome://extensions
  2. Enable Developer mode
  3. Load unpacked → ./extension

Environment variables are defined in .env.example; copy it to .env and fill SOLANA_RPC_URL and optional GROK_KEY. Run a scan from the UI or via curl http://localhost:5000/scan?address=....

Real‑World Use

# Inside a notebook
import requests
resp = requests.get('http://localhost:5000/scan', params={'address': 'A1B2C3...'})
print(resp.json()['score'])

The result instantly shows the bundle status and historical launch context.

Code Health & Issues

Tests – 12 test files covering Flask routes, launch worker, and extension messages.
CI – GitHub Actions workflow ci.yml runs lint, tests, and static analysis.
Licensing – MIT license present.
No structural red flags – dependency files (requirements.txt, package.json) are in sync; no secrets committed.

The Bottom Line

gem-search delivers a complete, locally hosted memecoin analysis stack with a modern web UI and browser integration. It is well‑tested, CI‑backed, and requires minimal configuration. Teams needing instant, private on‑chain insights can deploy it with the provided commands; developers can modify the worker logic or extension UI without touching unrelated modules.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

69 files

Python18
Markdown11
JavaScript8
JSON6
HTML3
CSS2

ReactFlaskExpress

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["tests 11 modules"] g1["(root) 5 modules"] g2["extension 5 modules"] g3["launch 4 modules"] g4["scripts 4 modules"] g5["static 2 modules"] g0 -->|14| g1 g0 -->|2| g3 g0 -->|1| g5 g0 -->|1| g2

Module dependencies

The 10 most depended-upon modules of 33, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_app["app"] n1_automation["automation"] n2_jev["jev"] n3_grok["grok"] n4_launch_guard["guard"] n5_launch_provider["launch_provider"] n6_extension_shared["shared"] n7_launch_transport["transport"] n8_static_capsule["capsule"] n9_tests_http_extension_smoke["http_extension_smoke"] n0_app --> n1_automation n0_app --> n3_grok n0_app --> n2_jev n1_automation --> n5_launch_provider n2_jev --> n1_automation n9_tests_http_extension_smoke --> n0_app n9_tests_http_extension_smoke --> n2_jev n9_tests_http_extension_smoke --> n3_grok

Dependencies

2 declared dependencies, none a major version behind. Resolved 2 of 2 against the registry.

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

medium4

low2

Enable Dependabot or Renovatemedium

2 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Give the outbound request a timeoutmedium

app.py

1 outbound call(s) with no timeout

requests has no default timeout, so a peer that accepts the connection and then says nothing holds the worker forever, and with a small worker pool a single slow dependency takes the whole service down without anything appearing to fail.

Fix: Pass timeout= on every call, or use a session with one configured.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow

.github/workflows/ci.yml

1 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.