How SolKnife works

Four things hold true across the whole toolkit:

• ▸Non-custodial. SolKnife never holds keys or funds. Every state-changing operation runs as: server builds an unsigned transaction → client verifies it against a program allowlist in the browser → wallet signs → server self-submits. The wallet's signature is the only authorization, and the server cannot alter the transaction after it is signed.
• ▸Fail-closed. A signal that cannot be verified renders as “cannot verify,” never as “safe.” A parse failure, an unreachable upstream, an edge case in an on-chain layout — all refuse to greenlight rather than guess.
• ▸Single-process, short cache. On-chain reads are cached briefly (typically 15s fresh / 60s stale) so a re-scan or re-quote is fast. Every report shows an “as of” time; re-run before you trade if the window has elapsed.
• ▸Transparent fees. Every fee SolKnife charges is shown in the quote or review screen before you sign. Nothing is charged without being visible first. The structured catalog of every fee is live on the pricing page.

The rug checker reads a token's mint account directly from the chain and probes Jupiter for a live sell route, then surfaces six signals as rows with their current values and a verdict (clear / risk / unverified).

• ▸Mint and freeze authority. Facts, not estimates. An active freeze authority means the issuer can freeze a holder's balance so they cannot sell; an active mint authority means the supply can still be inflated. A revoked authority shows as revoked.
• ▸Token-2022 extensions. The TLV blob is parsed in-house, not delegated to an aggregator. Each dangerous extension (transfer hook, permanent delegate, default-frozen, mint close authority, …) is flagged individually. A transfer hook is detected, but the hook's own program cannot be proven safe, so it is surfaced as a risk, not cleared.
• ▸Holder concentration. The largest token accounts, with known exchange and pool wallets excluded. A noisy signal — high concentration alone does not condemn a token, but stacks with others.
• ▸Liquidity. The token's DEX pairs and their depth in USD. Thin liquidity means a token may be hard to sell without heavy slippage.
• ▸Sellability. A live Jupiter sell-route probe. If no route exists, or only at an extreme price impact, the token is effectively unsellable. This is the core honeypot signal.
• ▸Token info. Softer context from Jupiter: how recently the mint was created, an organic-activity score, and a dev-wallet signal (tokens the creator has launched, share of supply still held). Provenance hints, never the verdict.

Four tools that cover the creator funnel end-to-end:

• ▸Create-mint generates a fresh mint keypair in the browser (single-use throwaway, never sent to the server) and builds the create-mint transaction. The user's wallet co-signs with the mint keypair. The structural verifier pins which programs the tx touches before the wallet sees it; an injected ix would be rejected client-side.
• ▸Mint-supply reads the mint to confirm the connected wallet is the current mint authority before enabling the form. Refuses to build a transaction the wallet can't actually authorize. Auto- creates the recipient's Associated Token Account in the same tx if it doesn't exist.
• ▸Token-metadata handles both Metaplex Token Metadata (SPL Token) and the Token-2022 built-in metadata extension automatically — the tool detects the program and picks the right path. Optional in-form Arweave builder uploads the image and the generated JSON directly to Arweave via the user's wallet (no SolKnife custody of either).
• ▸Revoke-authority reads authority state first and only enables revokes the connected wallet can sign. Both mint and freeze revoke fit in one tx; the user picks one or both. Revoking is permanent and one-way at the protocol level.
• ▸Change-authority is the reassign sibling of revoke: it transfers the mint and/or freeze authority to a new address (SetAuthority with COption::Some) rather than to None. The verifier pins the new authority in the transaction the browser checks before signing, and the structural re-check confirms only the signing wallet's own authority is moved, so execute can't reassign someone else's mint.

A non-custodial wrapper around Jupiter routing. The server asks Jupiter for the best route across every major Solana DEX (Orca, Raydium, Meteora DLMM, Phoenix, …), builds an unsigned transaction, and returns it to the browser.

Before the wallet sees the bytes, the browser-side verifier checks that every program the tx touches is in a known allowlist (Jupiter, the DEX programs Jupiter routes through, ATA program, Token / Token-2022, ComputeBudget). A malicious tx with an unexpected program is rejected client-side; the wallet never signs it.

The platform fee accrues as wrapped SOL to a fee account configured by the operator — visible on the quote before signing, deducted in the same transaction as the swap. Jupiter's own fee structure and the underlying pools' fees are also reflected in the quote.

The Token-2022 confidential-transfer extension: amount privacy (only) on Solana. Sender, receiver, and the fact of the transfer stay public on-chain; the amount is encrypted with ElGamal and readable only by the parties (and an auditor if the mint has one).

Key derivation. ElGamal and AES secret keys are derived in a browser Web Worker from a wallet signature on a fixed seed message (the SPL Token CLI standard, deterministic per RFC 8032 ed25519). The keys live in the worker for the session and are discarded on tab close. They never reach the server.

ZK proofs. Built in the worker: equality, range (64-bit for withdraw, 128-bit for transfer), validity, zero-ciphertext, and 3-handle proofs. Only the proof bytes and ciphertexts reach the server; the secret openings stay in the browser.

Saga signing. Withdraw is a 5-transaction saga; transfer is also 5. All signed in one wallet approval via signAllTransactions. If a saga is interrupted, the orphan-reclaim flow scans the chain for the context-state accounts your wallet authorized and closes them in a single approval (rent returned in full).

Strictly non-custodial. The user's wallet pays Irys directly via @irys/web-upload-solana; the file never reaches SolKnife's servers. There is no backend route for this tool — the whole flow runs in the browser against Irys.

Two signatures the first time: one to fund the wallet's Irys balance, one to upload the file. Returning users with an already-funded balance only sign the upload. Funding pre-funds the balance with a 10% buffer over the quoted upload cost to absorb price drift between funding and upload.

The same upload primitive is reused by the in-form Arweave builder in token-metadata: the shared IrysSession facade funds ONCE for the combined image + JSON cost and runs the two uploads back-to-back, so building a complete metadata URI for a fresh mint costs at most three signatures.

Reclaim-rent lists every token account in the wallet, flags the empty ones, and lets the user batch many closes into a single wallet approval via signAllTransactions. Only empty accounts (zero balance) can be selected; non-empty ones are shown but not selectable.

Burn-NFT lists the wallet's NFTs via the DAS API. Burn closes the NFT's token, metadata, and edition accounts in one tx per NFT; the rent from all three returns to the wallet. Programmable NFTs (pNFTs) are auto-thawed as part of the burn. Compressed NFTs (Metaplex Bubblegum) use a different program and are out of scope.

Multisig creates and runs a Squads Protocol v4 multisig. Create reads the Squads program config for the protocol treasury, then builds one transaction your wallet and a throwaway create-key co-sign (two signers); the structural verifier pins the create instruction, the two-signer shape, and the SolKnife fee before either signature is added.

A multisig is multi-party and asynchronous, so the on-chain accounts are the shared state and SolKnife stores nothing. Loading a multisig reads its members, threshold, vault balance, and pending proposals (with vote tallies) straight from chain. Proposing a transfer or a config change builds a Squads vault / config transaction plus a proposal, auto-approved by the proposer when they can vote; approving and executing are separate transactions each member signs from their own wallet. The verifier allows only the Squads, ComputeBudget, System, and Phantom-guard programs at the top level and pins the exact set of Squads instructions per action, so a tampered build cannot slip in an unrelated multisig instruction. The instructions a vault transaction runs are governed by the multisig's own threshold approval, not by this client-side gate. Config changes run through the same propose-and-vote flow; a membership change invalidates earlier pending proposals, which must be re-proposed.

The holdings tab reads the connected wallet's public token balances and links each holding into the rug-checker. Compose mode prices the same holdings against user-supplied target percentages, then can build a best-effort single Jupiter Router transaction. The wallet signs only after the user reviews that compose transaction.

On-chain reads go through a Helius RPC endpoint (key embedded server-side; never reaches the client). Token routes, prices, and token metadata come from Jupiter. NFT lookups use the Solana DAS API. Liquidity-pool data for DLMM tools uses Meteora's API. Every upstream has a per-process rate budget; when a budget is exhausted the caller serves cached data, returns a degraded status, or refuses — it never falls through to upstream unbounded.

SolKnife is automated on-chain analysis and transaction assembly. It is not financial advice. A passing rug-check is not a guarantee that a token is safe — a token can be safe one minute and rugged the next. A successful swap does not promise a successful sellback. A successful mint does not promise demand.

When a signal cannot be verified, SolKnife says so plainly. It never presents an unverified token as safe. That stance — refusing to claim what we cannot verify — is the durable part of the toolkit. Do your own research; SolKnife's job is to give you a clean, honest read of the on-chain facts.