Pumpx 2024 signer audit findings and remediation statuses
Pumpx underwent a December 2024 audit of its trusted execution environment (TEE) signer and selected backend services. The detailed register marks six findings as fixed and four as acknowledged. Those acknowledged items cover request replay, randomness, wallet derivation, and private key handling. Although the closing summary says all findings were fixed, individual entries retain different statuses. The result describes particular code revisions from that review, with distinctions among implemented changes, accepted explanations, and proposed product restrictions.
The short version: The December 2024 signer review left private key export acknowledged, so its pass result does not establish removal of that exposure.
Signer service and backend code within the review
The audited software supplied signing services for a decentralized exchange (DEX), with coverage extending to selected backend signing and wallet-export code. A TEE provides a protected environment for sensitive operations, including key handling. The review combined automated analysis with manual code inspection, using a white-box approach. It explicitly recorded no smart contract in its scope. Deposits and limit orders belong to the application’s wider trading context. This assessment concerned the signer and specified backend components, without establishing a product-wide assessment of every trading function.
What did fixed and acknowledged mean in this audit?
Fixed entries record remediation for the identified issue; acknowledged entries do not mark the issue fixed, and some include an explanation of the existing design. SlowMist’s December 23-27, 2024 review gave the project a pass. Its closing summary also asserted that all findings were fixed. The detailed register and individual finding sections nevertheless left four entries acknowledged.
Severity answers a separate question about the issue’s assessed significance. The single medium-severity entry concerned unchecked hexadecimal decoding and carried a fixed status, while the informational entry concerned wallet derivation compatibility and remained acknowledged. A low-severity finding could also carry either status. The closing summary lists medium, low, and suggestion categories; the detailed register also includes the informational derivation finding. Neither the severity rating nor the overall pass replaces the individual remediation record.
Corrections to connection checks and backend inputs
TLS certificate verification
The backend connection code set
InsecureSkipVerify
to true, disabling Transport Layer Security (TLS) certificate verification. The finding identified possible connections to untrusted servers and a man-in-the-middle attack route. Its correction enabled certificate verification, and the entry carries a fixed status.
Chain selection and signature checks
The inspected verification function could return success when
chainType
was 0, without running a signature check. Adding default handling addressed this bypass. A separate low-severity finding concerned the key-derivation function, where an unsupported chain type could leave its cryptographic scheme uninitialized. That entry also records a fixed status. The derivation switch selected the Elliptic Curve Digital Signature Algorithm (ECDSA) for its Ethereum Virtual Machine (EVM) case and Ed25519 for its Solana case. These were separate defects in different functions, despite their shared need to handle an unexpected chain type.
Malformed hexadecimal input
The conversion routine ignored the error from
hex.DecodeString
. Malformed hexadecimal input could therefore produce incorrect output. The correction required handling the decoding error and returning appropriate error information. The report marks this medium-severity finding fixed. The audited helper converted decoded bytes into Base64, making error handling part of that conversion path.
Encrypted data and console secrets
Authentication alongside encryption
The audited routine used Advanced Encryption Standard (AES) encryption in cipher block chaining (CBC) mode without authentication. The finding described a risk of ciphertext changes escaping detection. The correction adopted AES in Galois/Counter Mode (AES-GCM), combining encryption with authentication. The report classified this as a low-severity business-logic finding, with a fixed status for the reviewed routine. Protecting encrypted data against modification addresses a different exposure from exporting a private key outside the TEE.
Master-seed output during generation
The key-and-seed generation command printed sensitive information, including the master seed, which logging systems could collect in production environments. The relevant branch was
Commands::GenerateAuthKeyAndMasterSeed
. The finding called for avoiding sensitive console output and carries a fixed status. It did not change the separate acknowledgement attached to private key import and export.
Request replay and the stateless-server response
The replay finding concerned authorization logic accepting a previously valid signed request without a mechanism preventing its reuse. The proposed correction paired a timestamp or nonce with a validity check; adding a field without validation would not meet the described remedy. The entry remained acknowledged, with a response stating that the server’s stateless design would prevent actual harm. It did not mark a timestamp or nonce correction fixed. Signature validity and request freshness therefore remained distinct questions within the finding.
Which backend did the randomness explanation cover?
The explanation covered an SGX backend running Gramine, with the RDRAND x86 instruction supplying its random bytes.
The finding initially questioned the security of random-number generation within the TEE. Its proposed correction called for a TEE-specific generator. The cited implementation included
OsRng
and
thread_rng
calls; the acknowledgement addressed the existing runtime environment: Gramine used RDRAND as its random-byte source in the SGX backend. The finding retained its acknowledged status after the explanation. It described the named backend’s behavior during the review, without establishing the random source of every other TEE environment.
Wallet derivation and private key handling
Derivation paths and interoperability
The informational finding concerned a generated mnemonic derivation path which did not follow BIP44. The standard path shown in the audit was
m/purpose'/coin_type'/account'/change/address_index
. Its purpose, coin-type, account, change, and address-index levels describe branches within a wallet’s key hierarchy. The identified consequence was possible incompatibility with wallets or systems following that standard. The finding remained acknowledged. This concern involved how the implementation derived keys, separate from the signature-verification corrections and the encryption change.
Keys leaving the protected environment
The private key finding concerned import and export within the TEE application. Its discussion explained how export gave users more autonomy while exposing keys to an external environment. The recommendation called for changing the product to prevent access to private keys. The December 2024 register marked the private key import-and-export finding as acknowledged. The entry does not record implementation of that restriction.
Reconciling the pass result with individual findings
To check whether the audit records removal of private key export, compare its proposed correction and final status with those of the TLS finding.
| Review stage | TLS certificate checks | Private key export exposure |
|---|---|---|
| Covered code | Backend signer connection routine | Key export in the TEE application |
| Finding | Certificate verification disabled | Export could expose keys outside the protected environment |
| Proposed correction | Enable certificate verification | Change the product to prevent private key access |
| Final recorded status | Fixed | Acknowledged |
| Severity category | Suggestion | Suggestion |
The TLS entry records a completed correction. The export entry retains an acknowledgement, so the same pass result does not establish removal of export.
The audited revisions and later software
The review period ran from December 23 through December 27, 2024. Its coverage identified initial code revisions and separate final-review commits. The initial snapshots identify the examined starting code, while the final-review commits anchor the closing assessment.
The final-review signer commit was
c9d9e4f2f567578539b290924cbb5553f4995867
. The backend commit was
d0d1c91e48895ca39cc70d3693fdd61f6337b67b
. They distinguish the reviewed revisions from software bearing the same product name at another time.
A fixed status records the review’s conclusion about the relevant issue in that code context. Establishing the behavior of a later deployment requires its own revision and environment information. The audit does not identify the code behind every subsequent installation.
SlowMist’s statement limits the assessment to facts and supplied materials preceding issuance. It explicitly declines to judge later security conditions.
A later applicable review could change the assessment if it examines different code or updates individual findings. Any new conclusion would need to retain that review’s scope and environment conditions, including the backend qualification behind a randomness explanation.
What to know about Pumpx
How did the audited function verify Solana and EVM signatures?
The signature-verification function in the December 2024 audit used different methods for Solana and Ethereum Virtual Machine (EVM) signatures. The Solana branch used Ed25519 signature verification. The EVM branch recovered a signer address and compared it with the expected address. The chain-type bypass concerned a path which could avoid those branches. These details describe the examined function, without establishing the network coverage of later app releases.
Does the master-seed finding prove funds left a wallet?
The master-seed finding describes a possible information leak, without establishing an unauthorized transfer. The generation command printed sensitive information which a logging system could capture. Its fixed status concerns that console-output issue in the reviewed code. A finding about possible disclosure does not provide a transaction history, identify a particular affected wallet, or establish that an attacker obtained its funds.
Which findings belonged to the SAST category?
The December 2024 audit placed missing default handling and unchecked hexadecimal decoding in its static application security testing (SAST) category. It rated the first issue low and the decoding issue medium, then marked both fixed. The remaining entries appeared under business-logic security review. SAST identifies the audit category here; the separate severity and status fields describe each finding’s assessed significance and recorded resolution.
Did treasury and ordinary wallet accounts share the same derivation path?
The audited code constructed separate paths for treasury and ordinary wallet accounts. The treasury branch used a treasury label and wallet index. The ordinary wallet branch used a wallet label, a transformed omni-account identifier, and a wallet index. The derivation call separately received the selected chain type. These details describe the reviewed implementation, whose BIP44 compatibility finding remained acknowledged; they do not provide a general procedure for importing its wallets elsewhere.
Who requested the December 2024 signer audit?
SlowMist received the Litentry team’s security audit application on December 23, 2024. SlowMist’s security team performed the review of the TEE signer and selected backend code.