SECURITY VULNERABILITY REPORT
<Network> — <Severity> <Class> in <Component>
Date: YYYY-MM-DD
Status: <THEORETICAL | LOCAL REPRODUCED | TESTNET CONFIRMED | MAINNET CONFIRMED>


===============================
EXECUTIVE SUMMARY
===============================

<5–10 lines: what is broken, what the attacker gains, specific numbers>


===============================
VULNERABILITY DETAILS
===============================

Affected component:
  <file>:<lines>, <function name>

Root cause:
  <one or two sentences at the line level>

How it works:
  <EVM↔Cosmos mechanism, 1–3 paragraphs>

Technical prerequisite:
  <conditions for exploitation, if any>

Comparison with correct code:
  <adjacent correct function, if applicable>


===============================
EXPLOITATION STEPS
===============================

<numbered list with specific arguments and before/after state>


===============================
PROOF-OF-CONCEPT RESULTS
===============================

Test: <name> (<scale>)
  Contract:   <addr>
  Exploit TX: <hash>
  Block:      <number>
  <money-flow table>
  Status: CONFIRMED

Scaling economics:
  <fund → phantom → derivative → gas → profit>


===============================
IMPACT ASSESSMENT
===============================

Severity: <CRITICAL | HIGH | MEDIUM | LOW>

  1. <impact point>
  2. <impact point>
  ...


===============================
RECOMMENDED FIX
===============================

Immediate:   <Go diff / pseudo-diff>
Long-term:   <architectural proposal>
Audit:       <adjacent functions to review>


===============================
PROOF-OF-CONCEPT CODE
===============================

<full self-contained PoC>


===============================
DISCLOSURE TIMELINE
===============================

YYYY-MM-DD   <event>
YYYY-MM-DD   <event>

SECURITY VULNERABILITY REPORT
<Network> — <Severity> <Class> in <Component>
Date: YYYY-MM-DD
Status: <THEORETICAL | LOCAL REPRODUCED | TESTNET CONFIRMED | MAINNET CONFIRMED>

An attacker who starts with X native tokens ends up with X + profit
after a single exploit cycle. The profit scales linearly with the amount
invested. Gas cost is fixed regardless of exploit scale.

  Invested:            10 <token>
  Phantom balance:      5 <token>   (should be 0 after staking)
  Derivative received: 9.72 <lsd-token>
  Net profit:          +2.01 <token> equivalent

The attack is repeatable and can be looped for unlimited profit.

Affected component:
  precompiles/<module>/tx.go — function <FunctionName> (lines X–Y)

https://github.com/<org>/<repo>/blob/<commit>/precompiles/<module>/tx.go#LX-LY

Example: the exploit contract must perform at least one storage write (SSTORE)
before calling the vulnerable precompile, so the EVM stateObject is marked
"dirty" in the StateDB journal and the deduction is overwritten at commit.

// <AdjacentFunction> (correct):
if <condition> {
    p.SetBalanceChangeEntries(
        cmn.NewBalanceChangeEntry(callerAddr, amount, cmn.Sub),
    )
}

// <VulnerableFunction> — this block is missing entirely.

TX N — <stepName>():
  <describe what the tx does and why it is necessary>
  Calls:
    PRECOMPILE.<method>(
        arg1,   // description
        arg2,   // description
    )
  Expected (correct): balance decreases by X.
  Actual (buggy):     balance unchanged — phantom balance created.

STEP                 CONTRACT BALANCE    WALLET CHANGE        NOTES
----                 ----------------    -------------        -----
Start                0                                        wallet: NNN <token>
Fund contract        X                   -X
step1_setup()        X/2                 -gas                 X/2 locked
step2_exploit()      X/2  (PHANTOM)      -gas                 BUG: should be 0
step3_withdraw()     0                   +X/2                 phantom funds to wallet
step4_profit()       0                   +Y <lsd-token>       derivative to wallet

Fund amount    Phantom balance    Derivative received    Gas cost    Net profit
-----------    ---------------    -------------------    --------    ----------
10  <token>    5   <token>        ~9.7  <lsd>            ~C <token>  +P1 <token>
100 <token>    50  <token>        ~97   <lsd>            ~C <token>  +P2 <token>
1K  <token>    500 <token>        ~970  <lsd>            ~C <token>  +P3 <token>

Severity: CRITICAL

  1. Unlimited native token inflation — balance deduction is silently skipped.
  2. Direct profit extraction — no social engineering required.
  3. Repeatable and linearly scalable — gas is the only cost.
  4. Minimal prerequisites — <describe any required conditions>.
  5. Core module accounting corrupted — staking + bank state diverge.

// Add after the Cosmos-side operation call:
if err := stateDB.SetBalanceChangeEntries(
    cmn.NewBalanceChangeEntry(callerAddr, amount, cmn.Sub),
); err != nil {
    return nil, err
}

Adopt the upstream automatic BalanceHandler pattern (cosmos/evm ≥ v0.3.2).
It detects balance changes from Cosmos SDK events automatically,
eliminating the "forgotten SetBalanceChangeEntries" class entirely.

Audit ALL precompile functions that move native tokens for the same missing call.
Pay special attention to: <list adjacent functions worth reviewing>.