SignPath
Request Threat Brief
한국어로 보기
DPRK-focused Pre-Sign Security Layer

Stop Unsafe Signatures Before Assets Move

SignPath verifies transaction intent, execution path, signer authority, and policy context before digital assets move.

Built for exchanges, custodians, financial institutions, DeFi protocols, and treasury teams exposed to signer manipulation and operational workflow attacks.

Request Threat BriefBook Security ReviewSee how SignPath works

Protect the path to signing — not just the key.

  1. Request
  2. Approval
  3. SignPath Gate
  4. Signature
  5. Asset Movement
  • Transaction Intent
  • Execution Path
  • Signer Authority
  • Policy Context
SignPath Gate
  • ALLOW
  • HOLD
  • REJECT

Why Now

Attackers No Longer Just Steal Keys

Even legitimate signers and trusted systems can approve dangerous transactions through manipulated paths.

Past Attacks

  • Private key theft
  • Phishing
  • Malware
  • Direct intrusion

New Attacks

  • Legitimate approver
  • Manipulated signing request
  • Fake UI
  • Compromised developer environment
  • Valid signature
  • Asset theft

  • Bybit $1.5B Incident

    A large asset movement that appeared to pass normal approval procedures still resulted in catastrophic loss.

  • Target Scope Is Expanding

    Exchanges, DeFi services, bridges, RPC node operators, analytics firms, VASPs.

  • The Weak Point Is the Path

    The key may be secure, but the request reaching the signer may not be.

Source: FBI / IC3 Public Service Announcement on the Bybit incident (TraderTraitor).

Core Perspective

Signing Is the Final Moment

Once a valid signature is generated, prevention ends and incident response begins.

  • Intervention Possible
  • Irreversible
  1. Request
  2. Approval
  3. Pre-Sign Check
  4. Signingpoint of no return
  5. Broadcast
  6. Settlement

SignPath is the final control point before assets move.

Product Identity

SignPath Does Not Replace Wallets

We sit in front of HSM, MPC, Fireblocks, Safe, Squads, and internal signers to verify the path and intent of signing requests.

  1. Transaction Request
  2. SignPath Gate
    ALLOWHOLDREJECT
  3. Existing signers
    • HSM
    • MPC
    • Fireblocks
    • Safe
    • Squads
    • Internal Signer
  4. Signature
Gate decisionALLOWHOLDREJECT
  • No Replacement
  • Pre-Sign Gate
  • Runtime Provenance
  • Transaction Intent
  • Signer-Side Enforcement
  • Fail-Closed

We are not a company that stores keys. We verify the path right before keys are used.

Customers

Who Needs SignPath?

Any organization that moves digital assets or executes privileged onchain operations can be exposed to unsafe signing risk.

  • Custody & Financial Institutions

    Audit-ready signing control for institutional assets.

    Institutional Pilot

  • DeFi Protocols

    Protect admin, oracle, treasury, vault, governance execution.

    DeFi Threat Brief

  • Wallet & Infrastructure Providers

    Add a pre-sign gate to the signing workflow you already operate.

    Discuss Integration

Use Cases · Exchanges

For Exchanges: Verify Before Withdrawal

The biggest exchange risk is a large asset movement that appears to have passed normal approval procedures.

Where exchanges are exposed

  • Routine cold→hot with abnormal signing path
  • Whitelist change then large withdrawal
  • Compromised operator
  • Manipulated withdrawal request
  • MPC/HSM policy bypass
ALLOWHOLDREJECT

Before funds move, SignPath independently verifies the transaction, signer, path, and policy context.

Where SignPath sits in the withdrawal flow

  1. 01Internal Withdrawal Request
  2. 02SignPath VerificationIndependent pre-sign control point
  3. 03HSM/MPC Signature
  4. 04Onchain Transfer
  5. 05Audit Log

Use Cases · DeFi Protocols

For DeFi: Protect Privileged Operations Before They Are Signed

Audits protect contracts. SignPath protects the operational path before privileged transactions are signed.

Ethereum/EVM

Privileged operations protected before signing

  • Safe tx
  • Proxy upgrade
  • Admin function
  • Oracle update
  • Risk parameter
  • Contract allowance
  • Governance execution

SignPath interprets privileged EVM transactions before multisig execution.

Request DeFi Threat Brief

Use Cases · Custody & Financial Institutions

For Custody: Audit-Ready Signing Control for Institutional Assets

Institutional digital asset operations need evidence, accountability, and control before signatures are executed.

What institutional teams gain

  • 01
    Asset Protection
  • 02
    Audit Evidence
  • 03
    Policy Enforcement
  • 04
    Insurance Readiness
  • 05
    Regulatory Confidence

How It Works

Three Questions Before Every Signature

A transaction is signed only when the request, path, and signer are all verified.

  1. Is the request unchanged?

    • Canonical transaction payload
    • tx_payload_hash
    • Payload integrity

  2. Did it come through a trusted path?

    • Runtime event window
    • Process chain
    • File access
    • Network egress
    • runtime_provenance_digest

  3. Is the signer allowed to execute it?

    • signer_id
    • policy_hash
    • Decision artifact
    • Replay/TTL validation
Pre-sign decision
ALLOWHOLDREJECT
  • All verifiedALLOWthe request is signed
  • Needs reviewHOLDthe request waits for review
  • Unsafe/manipulatedREJECTthe request is stopped

No trusted path, no signature.

Decision Outcomes

Allow. Hold. Reject. Before Signing.

SignPath decides before signer execution — not after the transaction is broadcast.

  • ALLOW
    • Trusted request
    • Verified path
    • Authorized signer
    • Policy passed

    Trusted request and path verified.

  • HOLD
    • Additional review
    • New recipient
    • Unusual runtime path
    • High-risk method
    • Policy exception

    Needs manual review before execution.

  • REJECT
    • Payload mismatch
    • Invalid decision artifact
    • Unknown signer
    • Runtime provenance mismatch
    • Unsafe context

    Unsafe context or manipulation detected.

Fail-closed by default when trust is missing.

Before / After

Before SignPath vs After SignPath

Before SignPath

  • Approver checked
  • Signer checked
  • Policy checked
  • Execution path NOT checked
  • Runtime not bound
  • Evidence fragmented

Unsafe request may reach signer.

After SignPath

  • Request verified
  • Path verified
  • Signer verified
  • Policy verified
  • Decision artifact generated
  • Audit recorded

Unsafe request is held before signing.

The difference is not who signs. The difference is whether the path can be trusted.

Architecture

Runtime Provenance-Gated Signing Control

SignPath combines transaction payload, runtime provenance, signer identity, and policy context into one signing authorization decision.

End-to-end signing flow
  1. Transaction Request
  2. Payload Canonicalizer
  3. Runtime Collector
  4. Provenance Builder
  5. Policy / Decision Service
  6. Signer-Side Enforcement
  7. Signer
  8. Audit Sink

  1. Layer 1: Transaction Request

    • Raw tx
    • Safe tx
    • Squads tx
    • Fireblocks callback
    • HSM/MPC request
    • Internal signer request

  2. Layer 2: Payload Canonicalizer

    • Canonical payload
    • tx_payload_hash
    • Chain-specific normalization

  3. Layer 3: Runtime Collector

    • exec
    • open/openat
    • connect
    • Process chain
    • File access
    • Network egress

  4. Layer 4: Provenance Builder

    • Event window digest
    • runtime_provenance_digest
    • collector_id
    • Optional collector_signature

  5. Layer 5: Policy / Decision Service

    • signer_id
    • policy_hash
    • Risk rules
    • ALLOW/HOLD/REJECT
    • Signed decision token

  6. Layer 6: Signer-Side Enforcement

    • Public-key verification
    • TTL/replay check
    • Signer mismatch check
    • Fail-closed stop
    External

    Signer

    External signer (HSM/MPC/Fireblocks/Safe/Squads/internal) that SignPath sits in front of — not a SignPath layer.

  7. Layer 7: Audit Sink

    • Decision record
    • Execution result
    • Hash-chain audit log
    • Evidence export

Integration

Designed to Sit in Front of Existing Signing Infrastructure

No replacement. No migration. Add a pre-sign gate to the workflow you already use.

  • Local Signer Proxy

    For internal signer or hot wallet signer workflows.

  • HSM/MPC Adapter

    Before signing API calls or MPC signing requests.

  • Fireblocks Callback

    Evaluate transaction payload and context before callback approval.

  • Safe Module/Guard

    Pre-sign or pre-execution verification for Safe transactions.

  • Squads/Solana Adapter

    Interpret Solana instructions and authority changes before execution.

  • Custom API / Enterprise Gateway

    For exchanges, custody platforms, and internal wallet systems.

Threat Brief

Built for DPRK-Style Web3 Attacks

DPRK-linked attackers increasingly target people, developers, infrastructure, and signing workflows — not just contracts.

  • TV-01

    Fake Hiring

    Malicious repositories, fake interviews, developer environment compromise.

  • TV-02

    Fake Investor/Partner

    Social engineering through investment, partnership, or due diligence conversations.

  • TV-03

    Developer Compromise

    Account takeover, CI/CD abuse, package or deployment path manipulation.

  • TV-04

    Signer Manipulation

    Legitimate signers approving manipulated requests.

  • TV-05

    Operational Workflow Abuse

    Withdrawal requests, multisig approvals, admin actions, and treasury movements disguised as normal operations.

SignPath turns threat intelligence into pre-sign control.

Audit & Evidence

Every Signing Decision Must Be Explainable

SignPath records why a request was allowed, held, or rejected.

  • ALLOW
    1. 1
      Received
    2. 2
      Payload verified
    3. 3
      Path verified
    4. 4
      Policy passed
    5. 5
      Signature allowed
  • HOLD
    1. 1
      Risk signal
    2. 2
      Manual review
    3. 3
      Approval context requested
    4. 4
      Isolated from signer
  • REJECT
    1. 1
      Payload mismatch
    2. 2
      Invalid decision artifact
    3. 3
      Unknown signer
    4. 4
      Runtime provenance mismatch

Evidence left behind

  • EV-01

    Decision evidence

  • EV-02

    Execution record

  • EV-03

    Review workflow

  • EV-04

    Compliance export

  • EV-05

    Hash-chain audit log

Audit evidence is not an afterthought. It is part of the signing decision.

Pilot Program

Start With One Critical Signing Workflow

A SignPath pilot can begin in shadow mode without interrupting production operations.

  1. 1

    Signing Workflow Mapping

  2. 2

    Shadow Mode Integration

    observe, no block

  3. 3

    Risk Review Dashboard

  4. 4

    Controlled Enforcement

Start in shadow mode. Enforce only when the customer is ready.

Request Pilot

Contact

Request a SignPath Security Conversation

Tell us about your signing workflow. We will help assess where SignPath can reduce unsafe signing risk before assets move.

Required

Stop Hacks Right Before Signing

SignPath helps exchanges, custodians, DeFi protocols, and treasury teams stop unsafe signing requests before assets move.

  • Protect the path to signing
  • Verify transaction intent
  • Detect manipulated runtime paths
  • Hold risky requests
  • Reject unsafe signatures
  • Leave audit evidence

The safest signature is the one that never gets executed when the path is wrong.

Request Threat BriefBook Security Review