Security

#Your keys stay in your wallet

gitpad never asks for, receives or stores your seed phrase or private key. Every action that spends from your wallet (launching, trading, claiming discovery rewards) is a transaction that you review and sign in your own wallet. Wallet-binding messages are signed messages, not transactions, and cannot move funds.

If anyone claiming to be gitpad asks for a seed phrase or private key, it is not gitpad.

#What the server can sign

gitpad's web service holds two protected signing keys. They are server-only and are never sent to the browser.

Before a builder payout, the server checks that:

• the GitHub user currently has admin permission on the repository, confirmed with GitHub at that moment;
• the payout wallet was bound with a valid, unexpired, single-use signature;
• the claim review matches the exact amount, recipient and total already paid, and has not expired;
• the on-chain fee balance agrees with the indexed ledger.

The signed transaction is saved before it is broadcast, and a payout is marked settled only after the finalized transaction shows the bound wallet received exactly the reviewed amount. A payout whose outcome is unknown blocks another payout for that repository, so a timeout cannot cause a double payment.

#What the server cannot do

• It cannot sign from your wallet. It cannot launch, trade or spend on your behalf.
• It cannot withdraw migrated liquidity. The two positions created at graduation are permanently locked on chain.
• It cannot mint more tokens or freeze accounts. Token supply is fixed at launch.
• It cannot change a market's fee configuration. Fees are fixed by the market's on-chain configuration.
• It cannot redirect a builder payout to a wallet other than the one bound by a current admin. Claim requests carry no recipient or pool parameter.
• It cannot submit a discovery payout without the launcher. The claim transaction is prepared without the partner signature and only becomes valid after the launch wallet signs it.

#What depends on trusting gitpad

Builder fees, discovery rewards and platform fees sit under authorities held by gitpad's protected signers. Meteora enforces those signing authorities on chain, but it does not check GitHub identity. The rule that only a current GitHub admin's bound wallet can receive builder fees is enforced by gitpad's application, not by an on-chain escrow. The same is true of the discovery reward split.

This is a deliberate trade-off, disclosed here so you can assess it. See Risks.

#Other safeguards

• GitHub access. The GitHub App requests only repository Metadata: read. Your GitHub session lasts at most one hour and is stored encrypted in a Secure, HttpOnly cookie. Sensitive actions require a same-origin request.
• Wallet binding. Binding messages name the product, chain, repository ID, wallet, a one-time nonce and an expiry of five minutes.
• Accounting. Fees are credited only from finalized, canonical swap evidence, in integer base units, with each event recorded once.
• Worker isolation. The background worker holds no signing keys. It can only rebroadcast transactions that were already authorized and signed.
• Transaction review. Launches and trades are simulated before you are asked to sign, and receipts are checked against the canonical pool before being shown as confirmed.

#Audits

gitpad's code is covered by local integration tests against Solana and Meteora program fixtures. These are implementation evidence, not an independent audit. No completed external audit is claimed.

#Report a vulnerability

Please report security issues privately.

• Use GitHub's Report a vulnerability option on the gitpad repository if it is available, or contact the maintainers through an existing private channel.
• Do not post exploitable details, credentials, private keys or signed transactions in a public issue.

Include:

• the affected page, API route or source file;
• a minimal reproduction, using local fixtures where possible;
• the expected impact;
• relevant public transaction signatures, if any.

Do not test by moving other users' funds or by disrupting the production service. A dedicated security address, response time commitment and bug bounty have not been published.