Security and transparency
A launchpad should explain what is verified, what can be changed, and what remains a risk. This page describes the intended approach; it does not claim that contracts are deployed, audited, or production-secure.
A production deployment should publish verified source code and network-specific addresses. Independent audits should be linked to their actual reports, scope, date, and remediation status. A badge or interface label is not evidence of an audit.
Administrative permissions affect how a protocol can behave after launch. A design should document roles, multisignature ownership, timelocks, upgrade controls, and any emergency pause. Users need to know who controls those permissions and how they are constrained.
Escrow, settlement, fees, refunds, and liquidity should follow explicit contract rules. Client interfaces can help explain those paths, but the source of truth must be the deployed contract and verified chain events.
A launchpad should never request a wallet seed phrase or private key. Wallet providers handle signing, while the application displays the chain, destination, and action clearly. Users should independently verify transactions and understand that token launches can lose value.