Security boundary · Testnet · Risk-first

    MyCryptoPilot

    Demonstrate financial architecture without asking users to custody or copy funds.

    MyCryptoPilot is kept as a technical demonstrator. The public surface is limited to testnet, read-only connections and risk simulation; real copy trading, custody and return promises are out of scope.

    Role
    Solo security framing, architecture and full-stack development
    Period
    2026 hardening
    Status
    Demonstrator · testnet hardening pending
    MyCryptoPilot — interface principale

    Verifiable evidence

    482/482

    active tests

    Verified local baseline

    98

    build pages

    Reference production build

    Read-only

    exchange boundary

    No order permission expected

    0

    funds held

    No custody in the public scope

    How to read the numbers : Numbers are build and test evidence, not financial performance. Example data is explicitly labeled.

    Context and role

    The original signal and copy-trading theme creates immediate product risk: a persuasive interface can be read as a financial promise.

    The project is repositioned as an architecture and security case study with demo data and read-only connections.

    The priority is no longer executing a trade, but understanding exposure, drawdown and signal assumptions.

    Retained constraints

    • No custody, real orders or return promises.
    • Exchange keys must never be stored or logged in plain text.
    • Any displayed performance must be real and sourced or labeled as a deterministic example.
    • Demo / Testnet mode must remain visible everywhere.
    • Workers must be stoppable and observable without exposing secrets.

    Decisions and rejected options

    DECISION 01

    Simulation instead of execution

    An Execute Trade button implied a capability and responsibility the public product should not assume.

    Choice
    The Risk Console simulates exposure, size and scenarios without placing an order.
    Rejected
    Gradually enabling real copy trading.
    Trade-off
    Less transaction potential for a safer, technically more credible demonstrator.
    DECISION 02

    A read-only exchange boundary

    An over-permissive key turns an application leak into direct financial risk.

    Choice
    The target model validates permissions, rejects trading/withdrawal and supports explicit revocation.
    Rejected
    Requesting a universal key to simplify onboarding.
    Trade-off
    More configuration errors to explain with a much smaller blast radius.
    DECISION 03

    Deterministic examples

    Random or unsourced metrics look like achieved results.

    Choice
    Demo data is stable, identifiable and separate from read-only data.
    Rejected
    Keeping fictional marketing metrics to make the landing more persuasive.
    Trade-off
    A quieter presentation that remains reproducible in tests and honest to visitors.

    Journey architecture

    1. 01

      Demo mode

      Deterministic dataset, permanent badge and no dependency on a real account.

    2. 02

      Read-only connection

      Minimal permissions, protected secret and expected revocation.

    3. 03

      Normalized signal

      Assumptions, source and timestamp separated from execution.

    4. 04

      Risk Console

      Exposure, scenarios and limits simulated without real orders.

    5. 05

      Observable workers

      Async processing with a circuit breaker as the next reliability boundary.

    Quality and verification

    • 482 active local tests and a 98-page build.
    • Public navigation focused on Risk Console, Signals, read-only Portfolio, Traders and Account.
    • School, Tax, crypto payments and public copy trading blocked.
    • Fictional marketing metrics removed from the hero.
    • Permanent Demo / Testnet badge across exposed scope.
    MyCryptoPilot — vue produit

    What is actually delivered

    • A public promise focused on risk rather than returns.
    • An explicit boundary between examples, testnet and read-only data.
    • No public crypto payment, custody or copy-trading journey.
    • A broad test baseline from which to document the remaining hardening.

    Known limits

    • Full exchange-key permission validation still needs testnet E2E proof.
    • Price sources and PnL calculation must be explicit on every relevant view.
    • Circuit breaker, revocation and worker observability remain release criteria.
    • This project is neither financial advice nor evidence of returns.

    Next step

    • Add four testnet E2E flows: read-only connection, signal, risk simulation and revocation.
    • Verify no exchange secret appears in logs, traces or errors.
    • Document the threat model and price sources in the interface.

    Technical foundation

    • Next.js
    • React 19
    • TypeScript
    • Prisma
    • PostgreSQL
    • Exchange APIs
    • Workers
    • Vitest