Search Results

If it is an SPL token account, you can keep the account frozen, but that requires control over the freeze authority for the mint. … If you're using SPL token-2022, you can use the confidential transfer extension to prevent any transfers into the account. …

Only one transaction can get a write lock on an account at the same time. … If your on-chain program uses one big account for all of its state, and your instructions all write to that account, then the runtime will need to execute all transactions in serial. …

Looks like you can do it with the solana-php-sdk https://github.com/verze-app/solana-php-sdk with: use Tighten\SolanaPhpSdk\Keypair; $keypair = new Keypair(); // OR $keypair = Keypair::generate(); R …

This means you have to fetch a Data account, deserialize its data, and then call the function. This can be done on or off-chain. … (mut)] pub my_account: Account<'info, Data>, } After that, you'll have to read the returnData field from the simulation response: https://docs.solana.com/developing/clients/jsonrpc-api#simulatetransaction …

A stake account may be reused as many times as desired, but can only be delegated to one place at a time. …

For example, the native stake program allows you to withdraw all of the lamports in a deactivated staked account, which closes it. … Side note: I think it would be a great general interface to add, so programs can all implement the same instruction, and that way you can close any account! …

In your tests, if you're creating all of your accounts from one account, you'll be limited by the write throughput on that one account. … Since all of the creation transactions will take a write lock on the source account, they cannot be parallelized by the runtime, so you will get nowhere near 50k TPS. …

If you're using typescript, you can fetch the account with @solana/spl-token and check to see if it's frozen directly: import { getAccount } from '@solana/spl-token'; const accountInfo = await getAccount …

Once an account is assigned to a program C, the only way to re-assign it is through an instruction in program C. … For example, the token program assigns accounts back to the system program when an account is closed using account_info.assign(system_program::id()) at https://github.com/solana-labs/solana-program-library …

When Anchor closes an account, it transfers out all of the lamports from the account, which means that the account is eventually cleaned up by the runtime and can be reinitialized. … In the past, it would set a "tombstone" discriminator so that the account isn't "resurrected" later in the same transaction, and now it reassigns the account back to the system program and reallocates …

Accounts can be allocated up to that size if done at the top-level of the transaction, by adding a system_instruction::allocate and signing for the account in question. … The VM automatically adds 10KiB of padding after every single account that's provided to a program, in case the program reallocates the account. …

;, you're writing counter into the mutable byte slice of the account. … After the instruction, the runtime checks if the account data was changed, and then propagates those changes to the validator's accounts database. …

The --from parameter in create-stake-account will transfer funds from that account, and the --fee-payer will pay for it, so there's two problems. … Next, if the stake account has no SOL in it, it cannot be the fee payer or the "from" address, so make sure that it has funds in it. …

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 …

Transaction history is not stored longterm for devnet or testnet, so it's normal that you can't fetch old transactions on devnet. Mainnet-beta is the only network with longterm transaction storage. D …