Search Results

If a PDA is owned by the system program, then the only way to move lamports from that account is using invoke_signed to generate a "signature" from that PDA. … Even if an attacker knows everything about the PDA, your program must still authorize the moving of funds, so your program must be careful about providing "signatures" for the PDA. …

It's up to you, of course, but the easiest way would be to include an additional numerical seed in the PDA derivation, ie: Pubkey::find_program_address(&[b"one-to-many", user_pubkey, &[0]], program_id) …

To put it quickly, just don't worry about seeds at all and transfer to the address. They are used for TransferWithSeed, which is a pre-cursor to program-derived addresses. The concept is that with you …

As you noticed, PDA accounts are limited to an additional 10KB of account space on every invocation. …

It's technically possible that all address derivations will fail for the possible bump seeds, from 255 to 1. This is extremely unlikely, since there's about a 1 in 2^255 chance of no bump seed working …

There's a couple of questions here, and I think it'll help a lot if we separate them. To start, web and hardware wallets typically require manual confirmation for all transactions that the user signs …

Since you're passing in the seeds to invoke_signed, the runtime will check to make sure that one of the accounts can be promoted to a signer using the provided seeds. The runtime will perform create_p …

If IsOnCurve is false, it means the address is a program-derived address. If an exchange has control of that address in their program, they can update their program to do anything with it, including r …

An option is to add #[inline(never)] to any functions that InitiateWheel` might call into. For example, the spl-stake-pool program was having issues in its main processor function because the compiler …

For example, if program A calls to program B, program A can sign with a PDA and also provide the seeds used. … Program B can check that the PDA signed and that it was derived using a certain program id. If everything checks out, then program B can be sure that program A signed somewhere. …

You can read up on PDAs at https://solana.com/docs/core/pda and ownership at https://solana.com/docs/core/accounts#system-program …

You have two main options: iterate through all the possible combinations of seeds for a user. If you know that the current max round is 2000, you can try all possible 2000 entrant addresses and fetc …

The fourth account provided must be the mint, and not the funder. So instead, you should do: List<AccountMeta> metas= new ArrayList<>(); metas.add(new AccountMeta(funder,true,true)); …

The main thing to keep in mind is potential DOS opportunities from someone crafting transactions with different IDs to create accounts, and potentially take control of them, if that's part of your pro …

If they run concurrently, then your tests will compete to create the PDA, and potentially tear it down for each other! … Given all of that, I think your best option is to slightly redesign the program, so that no PDA is totally static. …