Security model
What PoolPort LiquiFi can do, what it can't do, and how you can verify both yourself.
Threat model
PoolPort LiquiFi is designed to protect against two classes of risk:
- Server compromise. If our servers were breached, an attacker should gain nothing of value — no keys, no funds, no ability to sign.
- Malicious operator. Even if we wanted to steal funds, the architecture should make it impossible without detection.
PoolPort LiquiFi does not protect against: a compromised browser extension, malware on your machine, a screen recorder, or a compromised RPC endpoint that returns false data. Those are outside our control.
Key handling
Your mnemonic is entered into an HTML <textarea>. It is processed
entirely in JavaScript, in the browser tab. It is never serialized, never stored in
localStorage, never sent to a server, and cleared from memory when you click "Clear"
or close the tab.
Derived private keys exist only in the JavaScript heap for the duration of a signing operation. They are not written to disk, not logged, and not included in any telemetry.
Verification: open DevTools → Network. Paste a mnemonic. Run a full preview. Search every request and response for any word from your phrase, any derived address, or any hex string longer than 32 characters. None appear.
Signing
All transaction signing happens locally:
- Mnemonic mode: keys are derived in-browser from the pasted phrase using
ethers,@solana/web3.js, andbitcoinjs-lib. Signing happens in the same tab. - Wallet extension mode: signing happens in your wallet (MetaMask, Rabby, etc.), which the browser mediates. We never see the key.
- WalletConnect mode: signing happens on your mobile wallet. We only relay the unsigned transaction payload.
- Ledger / Trezor: signing happens on the hardware device. You see every transaction on the device screen before approving.
No server-side component has the ability to construct, sign, or broadcast a transaction on your behalf.
What the servers do
PoolPort LiquiFi runs three Cloudflare Workers:
- RPC proxy — forwards JSON-RPC calls to Alchemy and Helius so we can hide our API keys. Logs only timestamp, IP, route, and status code. No payload content, ever.
- Payment worker — handles credit purchases (crypto), tracks balances keyed by a pseudonymous client ID, records sweep receipts for our own accounting, and independently verifies EVM fee receipts against on-chain transfer logs. Does not receive mnemonic data, private keys, or signed transaction payloads.
- Affiliate claim worker — periodically claims accumulated deBridge affiliate fees on Solana. Runs on a cron schedule; the manual trigger endpoint requires an operator secret. Only the operator's own Solana key is present on this worker, and it can only withdraw fees accrued to the fee wallet.
None of these workers can spend user funds, sign transactions on a user's behalf, or access user keys.
Release integrity
Every build publishes a SHA-256 hash at
/releases/latest.txt.
To verify the bundle you're running matches what we published:
curl -s https://liquifi.poolport.xyz/app.js | openssl dgst -sha256
The output should match sha256_hex in
latest.txt. If it doesn't, do not use the app.
The HTML additionally pins a Subresource Integrity (SRI) hash on
the script tag, so a tampered app.js arriving from
transit or a CDN would be refused by the browser. SRI does
not protect against a compromise of the origin
server itself — an attacker with write access to the origin
would update the HTML and the JS together. The
curl | openssl comparison above is the check that
matters for origin integrity, and it is only meaningful if you
compare against a hash you obtained through a channel
independent of our server.
In other words: SRI raises the cost of transit and CDN attacks to near zero. Defending against origin compromise requires either trusting us, or obtaining the release hash out of band and comparing it yourself. There is no purely-client-side way to close that gap.
Why the source isn't public
PoolPort LiquiFi's source is proprietary. This is a trade-off we discuss in detail at /private-source.html. Security researchers can request NDA access to the private repository by emailing info@poolport.xyz.
Reporting a vulnerability
If you believe you've found a security issue, email info@poolport.xyz. Include:
- A description of the issue
- Steps to reproduce
- Any proof-of-concept you can share safely
We aim to acknowledge within 72 hours. We do not currently run a paid bounty program, but we credit reporters (with permission) and grant NDA repo access to anyone who reports a valid issue.
What we will never do
- Transmit your mnemonic, seed, or private keys
- Sign transactions on your behalf
- Take custody of your funds
- Add telemetry that includes wallet contents or addresses
- Ship a release without publishing its hash