Account Creation Casper networks use an account-based model, in which each account can be uniquely identified by an Account Hash derived from a Public Key. This identification method allows Casper to support a variety of key variants by standardizing key length. Currently, Casper supports both Edwards-curve Digital Signature Algorithm, or Ed24419 keys, and Elliptic Curve Digital Signature Algorithm, or Secp256k1 keys. An account uses these keys to sign deploys sent to the network, allowing other entities to identify their origin point. Account creation on a Casper network involves creating a key pair of one Public Key and one Secret Key. Signing a deploy or interacting with the Casper network requires both keys. However, simply creating a key pair does not create a Casper account. Account creation requires funding the main purse associated with the accounts public key.

Multi-Signature Functionality Casper networks natively feature multi-signature functionality that allows granular security access via associated keys. Users can assign an action threshold to their accounts ability to send deploys or manage keys. Any associated key with a weight higher than the threshold can perform these actions. Alternatively, several associated keys with a combined weight higher than the threshold can sign the deploy or alter key management aspects. Different thresholds, weights, and number of associated keys can create a variety of security scenarios as required for a given operation. 4. Deploys

Deploy Structure Deploys are a data structure containing Wasm and the signature of the sending account. They are the method by which users can request changes to global state. A deploy contains session code executed in the callers context, which can, in turn, install or interact with contract code on the network itself. A deploy consists of a body containing payment and session code and a header containing the public key of the account, which will serve as the context for the deploy, a timestamp of the deploys creation, a time-to-live value that determines potential expiry, and a blake2b256 hash of the body as listed above. Further, it includes a deploy hash that is a blake2b hash of the header and a set of approval signatures that have signed the deploy. A successful deploy execution results in permanent changes to global state and will incur a proportional cost in CSPR based on the complexity and size of the deploy in question. Deploy Lifecycle

Deploy Received Clients first send their deploy to one or more nodes using the nodes JSON-RPC server. The node immediately checks that the deploy adheres to configuration settings outlined in the networks chainspec. If the node accepts the deploy as valid, the system returns a deploy hash to the client that can be used to monitor the status of the deploy in question. If a deploy reaches or exceeds the time-to-live setting, it will expire. Deploy Gossiped After accepting a new deploy, the accepting node will begin to gossip the deploy to all other nodes. This process ultimately leads to a validator node placing the deploy into the block proposer buffer, where the lead validator chooses deploys to create a new proposed block. Block Proposed The lead validator for the round proposes a new block to be added to the chain, which includes the maximum number of deploys from the block proposer buffer that fit in a block.