A Solana Pool Authority Needs Four Onchain Checks

To verify a Solana pool authority, confirm what it controls, which program governs it, how it relates to the pool’s token vaults, and whether the address matches the program’s rules. A copied address or explorer label can identify a candidate, but neither proves that it belongs to the pool you intend to inspect. The same distinction matters when comparing Byreal swaps and pools with a trading goal: the pool’s identity and its authority are related, but they are not interchangeable.

What does a pool authority address control?

A pool authority is an address with a defined role in a particular pool program; Solana has no universal pool-authority field that works across every exchange. Start with the pool account and the program that owns it. The owning program can modify its account data, while an authority recorded inside that data may be permitted to perform a narrower action, such as authorizing token transfers. Those are separate roles.

For a fuller walkthrough of matching pools and swaps to an objective, see this guide to matching Byreal swaps and pools with a trading goal. The address checks below focus on verifying who can act for a pool once you have identified it.

How can you check a Solana pool authority?

Check the account relationships in this order; a match on one field alone is not enough.

• Confirm the pool account. Fetch it from the intended network and check that its account data is present and owned by the expected pool program. An explorer name or token pair alone can point to a different or imitation pool.
• Read the authority field in context. Decode the pool data using the program’s documented layout or interface definition. Confirm that the candidate address appears in the field the program uses for the role you care about; don’t confuse it with the pool address, fee recipient, or upgrade authority.
• Trace the vaults and their mints. Verify that each vault is a token account for the expected mint and that its token-account authority matches the pool’s documented setup. A token account is owned at the program level by the Token Program or Token-2022, while its stored authority is a distinct field.
• Verify the derivation or signer model. If the authority is a program-derived address (PDA), reproduce it from the expected program ID and seeds, using the pool’s documented derivation. A PDA has no private key; its program authorizes it through a signed cross-program invocation. If the address is a wallet or multisig instead, check the program’s rules for that setup.

How does this compare with a wallet or token authority?

A normal wallet address is controlled by its private key; a PDA is controlled through its deriving program. Neither form alone proves that an address is the right authority for a specific pool. Likewise, a mint authority governs token issuance and a freeze authority can freeze token accounts, but those roles do not make either address the pool authority. Token-2022 can add further mint-level permissions, so inspect relevant extensions when evaluating token controls.

For most readers, the strongest evidence is agreement between the pool’s decoded state, its program’s documented derivation or signer rules, and the vaults’ mint and authority fields. Watch for changes to the pool’s authority or program, mismatched vault mints, and new token extensions or permissions. These signals can change what an address can do even when the pool label stays the same.