In our previous post we peeked into what is under the hood of Solana's Accounts Model.

Accounts Model | PDA

If we inspect closely, the&nbsp;createAccount&nbsp;method expects a public key. So we must create the public key for the account before attempting to create an account. (Creating really means to allocate and assign)

We could create a new key pair and then pass it to createAccount.

However, if we are generating a private key for every new account we are creating that’s a tonne of private keys to maintain and to sign in any transaction. What if we could generate an address or publickey deterministically like&nbsp;we did when we hashed the&nbsp;userId

Since the user can interact with multiple programs, we probably want to capture the&nbsp;programId&nbsp;and create an account specifically for this program.

It generates a public key by using a sha256 hash of the seeds, the key thus generated may however be on the curve, which means that it can have an associated private key. If there is a private key it would mean that someone who has access to the private key, it opens up a possibility that someone can sign for the transaction and imitate the program or we need to securely store this private key, all of this could be a security risk. We address this by creating a public key which will never have a private key, no private key means no need to manage it.

We do this by padding the seeds with a fudge factor called bump, the bump is decreased until a point that is away from the curve is found.

For the mathematically curious I recommend watching this computerphile video to understand how elliptic curve cryptography works.

The added benefit of deriving the address from the program itself is that we can make the program sign for the addresses. But, how does a program sign for this? Simple it doesn’t, it just convinces the runtime that an existing signature is a stand-in for its signature. i.e the runtime will accept the signature if there is a valid signature in the original transaction

Since&nbsp;findProgramAddress&nbsp;has to run until an appropriate key is found, this can easily get computationally expensive, especially when doing this on-chain. A common practice is to store the bump, during initialization and on subsequent instructions, use the inexpensive&nbsp;create_program_address&nbsp;to verify the account with the bump.

An attacker can piece together a PDA using the published scheme and pass the account. In addition to storing and verifying the PDA using bumps, The program must also require the signature of the original user in every transaction. In order to do this, a common pattern is to store an authority which is the public key that created it.

00ca0d8f31290f4a65acf2dd8df316bfa6a2113dd150186f70a6d5fe14f64d0d