docs: update documentation for v1.1.0 release

.env.example

@@ -2,7 +2,8 @@
 MAINNET_RPC_URL=https://eth-mainnet.alchemyapi.io/v2/<API-KEY>
 
 # -------- For scripts --------
-# Etherscan API key for mainnet/goerli/sepolia, primarily used for contract verification.
+# Etherscan API key, primarily used for contract verification. When deploying and verifying
+# contracts, the API key needs to match the network of the `SCRIPT_RPC_URL`.
 # Note that this can also be helpful for running tests to provide more information on
 # traces during fork tests. For that use case, you may want to include a mainnet API key here when
 # running `forge test`

CODEOWNERS

@@ -1 +1 @@
-*       @austingreen @0xrajath @dd0sxx
+*       @austingreen @0xrajath

docs/README.md

@@ -33,3 +33,4 @@ To learn more about how the Llama framework works, read our documentation and us
 - [Strategies](https://github.com/llamaxyz/llama/blob/main/docs/strategies.md)
 - [Accounts](https://github.com/llamaxyz/llama/blob/main/docs/accounts.md)
 - [Instance deployment](https://github.com/llamaxyz/llama/blob/main/docs/instance-deployment.md)
+- [Scripts](https://github.com/llamaxyz/llama/blob/main/docs/scripts.md)

docs/accounts.md

@@ -13,9 +13,16 @@ There are also additional functions to batch transfer tokens to multiple recipie
 Instances can deploy dedicated accounts for different organizational functions and permission each function independently.
 For more granular fund management rules, instances can implement [guards](https://github.com/llamaxyz/llama/blob/main/docs/actions.md#guards) to set requirements based on token amount, frequency of transfer, market conditions, or any other rule(s) that can be expressed as code.
 
-## Arbitrary execute
+## Arbitrary Execute
 
 The account contract also includes an `execute` function that allows for arbitrary calls and code execution. Actions that call this function can be used to call or delegatecall a target contract with specified calldata. This ensures that non-standard tokens will not be stuck in the account and accounts can interact directly with external contracts when necessary.
 Allowing delegatecalls means that accounts can expand their functionality over time. They can use periphery contracts that enable token streaming, vesting, swapping, and allow those contracts to execute code in the account’s context. Arbitrary execution is a powerful concept with important security considerations, so best practices should be followed when using this function.
 
 Instances should stick to the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and limit which policyholders are granted permission to create actions for this function. Guards are recommended to define which targets can be called, whether it uses a call or delegatecall, and to limit acceptable parameters that can be used.
+
+## Account With Token Delegation
+
+In addition to the standard [LlamaAccount](https://github.com/llamaxyz/llama/blob/main/src/accounts/LlamaAccount.sol) logic contract, we've also created a logic contract for governance token delegation.
+[LlamaAccountWithDelegation](https://github.com/llamaxyz/llama/blob/main/src/accounts/LlamaAccountWithDelegation.sol) inherits all the functionality provided in [LlamaAccount](https://github.com/llamaxyz/llama/blob/main/src/accounts/LlamaAccount.sol), but also includes functions for delegating governance tokens to a delegatee and batch delegating multiple governance tokens to multiple delegates.
+This is useful for unlocking the voting power of governance tokens.
+For example, these tokens can be delegated to an instance's executor contract, so the instance can vote with the governance tokens held in its accounts.

docs/actions.md

@@ -14,6 +14,7 @@ Actions are composed of the following parameters:
 
 ## Key Concepts
 
+- Llama Instance: The unique `LlamaCore`, `LlamaPolicy`, and `LlamaExecutor` addresses for a deployment.
 - [`LlamaCore`](https://github.com/llamaxyz/llama/blob/main/src/LlamaCore.sol): Manages the action process from creation to execution.
   - Actions: Proposals made by policyholders to execute onchain transactions.
   - Strategies: A contract that holds all of the logic to determine the rules and state of an action. For example, strategies determine whether or not an action is approved/disapproved, canceled, or able to be executed. They also determine details around who is allowed to cast approvals/disapprovals.
@@ -24,7 +25,6 @@ Actions are composed of the following parameters:
   - Roles: A signifier that is used to permission action creation, approval, and disapproval. Any role can be given to one or more policyholders.
   - Permission IDs: A unique identifier that can be assigned to roles to enable action creation. Permission IDs are represented as a hash of the target contract, function selector, and strategy contract. Actions cannot be created unless a policyholder holds a role with the correct permission.
 - [`LlamaExecutor`](https://github.com/llamaxyz/llama/blob/main/src/LlamaExecutor.sol): The single exit point of a Llama instance. All actions that are executed will be sent from the Llama executor. This is the address that should be the `owner` or other privileged role in a system controlled by the llama instance.
-- Llama Instance: The unique `LlamaCore,`LlamaPolicy`, and`LlamaExecutor` addresses for a deployment.
 - `approvalPeriod`: The length of time that policyholders can approve an action.
 - `queuingPeriod`: The inverse of the approval period that can also be thought of as the disapproval period; defines the amount of time that policyholders have to disapprove an action.
 
@@ -101,13 +101,14 @@ Like the name suggests, if a policyholder with a force role casts their approval
 
 ## Scripts
 
-Scripts are the term used to refer to target contracts that are called via `DELEGATECALL` instead of a normal `CALL`.
-The main use-case for scripts is to batch multiple calls together into one action.
-In particular, scripts should be used to batch calls that are regularly made in tandem with one another to perform maintenance or other recurring tasks.
+By default [LlamaExecutor](https://github.com/llamaxyz/llama/blob/main/src/LlamaExecutor.sol) will call its targets using a low level `call` unless that target is a script.
+Scripts are target contracts that are called using `delegatecall` instead of `call`.
+To specify a target as a script, a policyholder must create an action that calls the `setScriptAuthorization` function on `LlamaCore` with the target address and `isAuthorized` set to `true`.
+Targets can be removed as scripts by creating an action that calls the `setScriptAuthorization` function with the same target address and `isAuthorized` set to `false`.
 
-`DELEGATECALL` is dangerous to use by default, so scripts must be authorized before use.
-To authorize a script, a policyholder must create an action that calls the `setScriptAuthorization` function on `LlamaCore`.
-Scripts may also be unauthorized using the same function.
+Scripts allow Llama instances to execute arbitrary code in the context of `LlamaExecutor`.
+This makes them useful for defining repeatable workflows that aren't included in the `LlamaCore`, `LlamaPolicy`, or in the instance's protocol contracts.
+Although most scripts will be protocol specific, the [Scripts](https://github.com/llamaxyz/llama/blob/main/docs/scripts.md) section documents examples that are useful across all instances.
 
 ## Guards
 

docs/scripts.md

@@ -0,0 +1,26 @@
+# Scripts
+
+By default [LlamaExecutor](https://github.com/llamaxyz/llama/blob/main/src/LlamaExecutor.sol) will call its targets using a low level `call` unless that target is a script.
+Scripts are target contracts that are called using `delegatecall` instead of `call`.
+To specify a target as a script, a policyholder must create an action that calls the `setScriptAuthorization` function on `LlamaCore` with the target address and `isAuthorized` set to `true`.
+Targets can be removed as scripts by creating an action that calls the `setScriptAuthorization` function with the same target address and `isAuthorized` set to `false`.
+
+Scripts allow Llama instances to execute arbitrary code in the context of `LlamaExecutor`.
+This makes them useful for defining repeatable workflows that aren't included in the `LlamaCore`, `LlamaPolicy`, or in the instance's protocol contracts.
+
+## Security
+
+Any low level calls made by scripts will use the instance's executor as `msg.sender`.
+Policyholders should review target contracts being authorized to ensure that this power isn't being abused.
+
+Llama's architecture is designed to limit this attack surface area.
+Since the `executeAction` on `LlamaCore` does not call targets directly and only interacts with external contracts through the `LlamaExecutor`, scripts can't access `LlamaCore`'s storage.
+
+## Examples
+
+All the scripts listed below have been audited and deployed to all networks supported by Llama unless otherwise stated.
+The contract addresses can be found in the [deployments section](https://com/llamaxyz/llama/blob/main/README.md#deployments) of the README.
+
+- **LlamaGovernanceScript:**: defines common governance workflows and batch functions for managing a Llama instance.
+- **LlamaAccountTokenDelegationScript:** leverages the `LlamaAccount` arbitrary execute function to allow users to delegate governance tokens from their Llama accounts. This is useful if an instance is using a standard `LlamaAccount` and doesn't want to transfer assets.
+- **LlamaInstanceConfigScriptTemplate:** can be used in conjunction with [ConfigureAdvancedLlamaInstance](https://github.com/llamaxyz/llama/blob/main/script/ConfigureAdvancedLlamaInstance.s.sol) to deploy and configure a new Llama instance by writing code. This is more expressive than the default JSON-based configurations.