Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create page for concepts #693

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions pages/advanced/_meta.json
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
"title": "Safe Smart Account"
},
"smart-account-overview": "Overview",
"smart-account-concepts": "Concepts",
"smart-account-modules": "Safe Modules",
"smart-account-guards": "Safe Guards",
"smart-account-signatures": "Signatures",
Expand Down
62 changes: 62 additions & 0 deletions pages/advanced/smart-account-concepts.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
### Concepts

#### Owners

Each Safe account maintains its own list of [owners](/home/glossary#owner) in the storage in the form of Ethereum addresses. Owners can be added or removed by other owners.

#### Threshold

Safe Smart Account maintains a [threshold](/home/glossary#threshold), the minimum number of owners required to confirm a transaction before it gets executed. The threshold of owners required to confirm a transaction is also stored in the storage. Owners of a Safe account can change the threshold value as well. A Safe account can have any number of owners, and the threshold value can be set between one and the total number of owners.

#### Signature verification

Safe Smart Account, being a contract account, does not have a private key to sign transactions, and EVM cannot verify incoming transactions to a contract account. Hence, a contract account has to do the authentication and authorization in its code. When a transaction is submitted to a Safe account, it is first verified by the Safe account to ensure that the transaction is valid. If the required number of owners has signed the transaction, the transaction is allowed to be executed. If the required number of owners has not signed the transaction, the transaction reverts to the signature validation step.
A Safe Smart Account verifies if each signer is an owner of the Safe account and verifies the signature based on the signature type. To learn more about the signature types supported by Safe and encoding, refer to the [Signatures](/smart-account-signatures) page.

#### Transaction flow

Transactions through a Safe Smart Account can be primarily divided into two types:

##### Safe Transaction

Safe Smart Account contract provides `execTransaction` function to submit and execute a Safe transaction which is signed by the owners of the Safe Smart Account.

To execute a transaction with the Safe Smart Account, the `execTransaction` method needs to be called with the following parameters:

- `to`: The recipient address of the transaction.
- `value`: The amount of Ether (in wei) to send with the transaction.
- `data`: The data payload of the transaction, typically used to call a function on the recipient contract.
- `operation`: Safe Smart Account supports `CALL` and `DELEGATECALL.`
- `safeTxGas`: Gas that should be used for the Safe transaction.
- `baseGas`: This is the amount of gas independent of the specific Safe transactions, but used for general things such as signature checks and the base transaction fee. `SafeTxGas` and `baseGas` combined are comparable to the gas limit of a regular transaction.
- `gasPrice`: Same like for a regular Ethereum transaction. Setting the gas price to 0 means that no refund is paid out.
- `gasToken`: For regular Ethereum transactions, gas is always paid in Ether. A Safe Smart Account enables users to pay in ERC20 tokens or Ether. The desired token is specified here. If `0x0`, then Ether is used. Gas costs are calculated by `(baseGas + txGas) * gasPrice`.
- `refundReceiver`: The refund does not necessarily have to go to the account submitting the transaction but can be paid out to any account specified here. If set to `0`, `tx.origin` will be used.
- `signatures`: All parameters are used to generate a transaction hash and signed by the owners of the Safe Smart Account. A list of hex encoded signatures is expected (`execTransaction` expects that the signatures are sorted by owner address. This is required to easily validate no confirmation duplicates exist).

##### Module Transaction

Safe Smart Account contract provides `execTransactionFromModule` and `execTransactionFromModuleReturnData` functions to accept transactions from modules. A module can be any Ethereum address and can bypass signature verification logic to execute transactions through a Safe Smart Account.

- `to`: The recipient address of the transaction.
- `value`: The amount of Ether (in wei) to send with the transaction.
- `data`: The data payload of the transaction, typically used to call a function on the recipient contract.
- `operation`: The type of operation to execute, either `CALL` or `DELEGATECALL.`

Here are some core components of a Safe Smart Account that you will learn about:

#### Safe Modules

[Safe Modules](/home/glossary#safe-module) are smart contracts that extend Safe's functionality with added custom features while the module logic remains separate from Safe's core contracts.

More information is available in the [Safe Modules ](smart-account-modules.mdx) page.

#### Safe Guards

[Safe Guards](/home/glossary#safe-guard) make checks before and after a Safe transaction.

More information is available in the [Safe Guards](smart-account-guards.mdx) page.

#### Signatures

Safe Smart Account support alternative signature schemes such as [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) and [EIP-712](https://eips.ethereum.org/EIPS/eip-712) and relaying by making the confirmation/verification logic independent of `msg.sender`. Read more about the [signature schemes](https://github.com/safe-global/safe-smart-account/blob/main/docs/signatures.md) supported by Safe.
63 changes: 0 additions & 63 deletions pages/advanced/smart-account-overview.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -110,66 +110,3 @@ Guards are used to check if a transaction should be executed or rejected based o
A Safe Proxy is a contract that delegates all calls to the Safe Singleton. Deploying a Proxy reduces the cost of creating a Safe account, as the proxy contract's byte code size is less than that of the actual Safe contract code.

![Safe Proxy Creation](../../assets/diagram-safe-smart-account-proxy-creation.png)

### Concepts

#### Owners

Each Safe account maintains its own list of [owners](/home/glossary#owner) in the storage in the form of Ethereum addresses. Owners can be added or removed by other owners.

#### Threshold

Safe Smart Account maintains a [threshold](/home/glossary#threshold), the minimum number of owners required to confirm a transaction before it gets executed. The threshold of owners required to confirm a transaction is also stored in the storage. Owners of a Safe account can change the threshold value as well. A Safe account can have any number of owners, and the threshold value can be set between one and the total number of owners.

#### Signature verification

Safe Smart Account, being a contract account, does not have a private key to sign transactions, and EVM cannot verify incoming transactions to a contract account. Hence, a contract account has to do the authentication and authorization in its code. When a transaction is submitted to a Safe account, it is first verified by the Safe account to ensure that the transaction is valid. If the required number of owners has signed the transaction, the transaction is allowed to be executed. If the required number of owners has not signed the transaction, the transaction reverts to the signature validation step.
A Safe Smart Account verifies if each signer is an owner of the Safe account and verifies the signature based on the signature type. To learn more about the signature types supported by Safe and encoding, refer to the [Signatures](/smart-account-signatures) page.

#### Transaction flow

Transactions through a Safe Smart Account can be primarily divided into two types:

##### Safe Transaction

Safe Smart Account contract provides `execTransaction` function to submit and execute a Safe transaction which is signed by the owners of the Safe Smart Account.

To execute a transaction with the Safe Smart Account, the `execTransaction` method needs to be called with the following parameters:

- `to`: The recipient address of the transaction.
- `value`: The amount of Ether (in wei) to send with the transaction.
- `data`: The data payload of the transaction, typically used to call a function on the recipient contract.
- `operation`: Safe Smart Account supports `CALL` and `DELEGATECALL.`
- `safeTxGas`: Gas that should be used for the Safe transaction.
- `baseGas`: This is the amount of gas independent of the specific Safe transactions, but used for general things such as signature checks and the base transaction fee. `SafeTxGas` and `baseGas` combined are comparable to the gas limit of a regular transaction.
- `gasPrice`: Same like for a regular Ethereum transaction. Setting the gas price to 0 means that no refund is paid out.
- `gasToken`: For regular Ethereum transactions, gas is always paid in Ether. A Safe Smart Account enables users to pay in ERC20 tokens or Ether. The desired token is specified here. If `0x0`, then Ether is used. Gas costs are calculated by `(baseGas + txGas) * gasPrice`.
- `refundReceiver`: The refund does not necessarily have to go to the account submitting the transaction but can be paid out to any account specified here. If set to `0`, `tx.origin` will be used.
- `signatures`: All parameters are used to generate a transaction hash and signed by the owners of the Safe Smart Account. A list of hex encoded signatures is expected (`execTransaction` expects that the signatures are sorted by owner address. This is required to easily validate no confirmation duplicates exist).

##### Module Transaction

Safe Smart Account contract provides `execTransactionFromModule` and `execTransactionFromModuleReturnData` functions to accept transactions from modules. A module can be any Ethereum address and can bypass signature verification logic to execute transactions through a Safe Smart Account.

- `to`: The recipient address of the transaction.
- `value`: The amount of Ether (in wei) to send with the transaction.
- `data`: The data payload of the transaction, typically used to call a function on the recipient contract.
- `operation`: The type of operation to execute, either `CALL` or `DELEGATECALL.`

Here are some core components of a Safe Smart Account that you will learn about:

#### Safe Modules

[Safe Modules](/home/glossary#safe-module) are smart contracts that extend Safe's functionality with added custom features while the module logic remains separate from Safe's core contracts.

More information is available in the [Safe Modules ](smart-account-modules.mdx) page.

#### Safe Guards

[Safe Guards](/home/glossary#safe-guard) make checks before and after a Safe transaction.

More information is available in the [Safe Guards](smart-account-guards.mdx) page.

#### Signatures

Safe Smart Account support alternative signature schemes such as [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) and [EIP-712](https://eips.ethereum.org/EIPS/eip-712) and relaying by making the confirmation/verification logic independent of `msg.sender`. Read more about the [signature schemes](https://github.com/safe-global/safe-smart-account/blob/main/docs/signatures.md) supported by Safe.
Loading