keyspace-client

README.md

@@ -46,7 +46,7 @@ bun run scripts/get-account.ts
 | Argument | Environment Variable | Description |
 | --- | --- | --- |
 | --private-key | PRIVATE_KEY | secp256k1 private key or P256 JWK |
-| --signature-type | | secp256k1 (default) or webauthn |
+| --signature-type | | secp256k1 (default) or WebAuthn |
 
 ### Send ETH
 ```bash
@@ -60,7 +60,7 @@ bun run scripts/send-eth.ts
 | --initial-config-data | | The initial config data needed to deploy the wallet |
 | --private-key | PRIVATE_KEY | secp256k1 private key or P256 JWK |
 | --to | | The address to send to |
-| --signature-type | | secp256k1 (default) or webauthn |
+| --signature-type | | secp256k1 (default) or WebAuthn |
 
 Make sure there's ETH in the account you're sending from. You can get the Ethereum address of the smart wallet by running `bun run scripts/get-account.ts`.
 
@@ -78,7 +78,7 @@ bun run scripts/change-owner.ts
 | --private-key | PRIVATE_KEY | Current private key of the owner |
 | --config-data | | Current config data for the keystore wallet (hex string) |
 | --owner-bytes | | The owner bytes to change in the keystore wallet |
-| --signature-type | | secp256k1 (default) or webauthn |
+| --signature-type | | secp256k1 (default) or WebAuthn |
 | --remove | | Flag to remove the owner instead of adding (optional) |
 
 ## Build Documentation

docs/pages/index.mdx

@@ -5,7 +5,7 @@ description: How to use Keyspace to build cross-chain wallets and other applicat
 
 # Getting Started
 
-Keyspace is a keystore for cross-chain smart wallets that keeps their configuration in sync. The primary goal of the project is to help wallet vendors build smart wallets that match the cross-chain user experience of externally-owned accounts in Ethereum: one address can be used on all current and future chains. Keyspace can also be used to build new wallet experiences where a user can manage many different accounts transparently share the same configuration.
+Keyspace is a keystore for cross-chain smart wallets that keeps their configuration in sync. The primary goal of the project is to help wallet vendors build smart wallets that match the cross-chain user experience of externally-owned accounts in Ethereum: one address can be used on all current and future chains. Keyspace can also be used to build new wallet experiences where a user can manage many different accounts that transparently share the same configuration.
 
 We believe that ERC 4337 smart wallets are the future: passkey signers, paymasters, and batch transactions dramatically improve the experiences builders can provide for their users. But to deliver on that promise, we need users to be confident that assets sent to their Ethereum address are in their control, regardless of what chains those assets are on.
 
@@ -14,6 +14,7 @@ Keyspace is built by the Base team as open, neutral infrastructure for all chain
 <iframe width="560" height="315" src="https://www.youtube.com/embed/DibVD2gCyp8?si=OCBQbDiFRBuZaxs2" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
 
 * [Keyspace on GitHub](https://github.com/base-org/keyspace)
-* [Coinbase Smart Wallet](https://www.smartwallet.dev/) Keyspace integration
+* Coinbase Smart Wallet
   * [JavaScript Client](https://github.com/base-org/keyspace-client)
   * [Smart Contracts](https://github.com/niran/smart-wallet/tree/keyspace)
+

docs/pages/keystore-basics.mdx

@@ -9,7 +9,7 @@ description: Learn the fundamental concepts and operations of Keyspace keystores
 
 In Keyspace, a wallet's cross-chain keystore is typically embedded within the wallet's smart contract. When you inherit from the `Keystore` contract, your wallet gains the ability to sync its configuration across chains.
 
-Since a `Keystore` needs know how to read its storage across chains, the logic for verifying cross-chain proofs from your wallet's master chain needs to be provided. The `OPStackKeystore` contract shipped with Keyspace provides this logic for OP Stack L2s.
+Since a Keystore needs to know how to read its storage across chains, the logic for verifying cross-chain proofs from your wallet's master chain needs to be provided. The OPStackKeystore contract included with Keyspace provides this logic for OP Stack L2s.
 
 ## Configuration Hooks
 
@@ -42,7 +42,7 @@ require(isNewConfigValid, InvalidNewKeystoreConfig());
 
 `_hookIsNewConfigAuthorized(ConfigLib.Config calldata newConfig, bytes calldata authorizationProof)`
 
-This hook is called before the configuration update is applied. It should verify that the caller is authorized to change the configuration. `authorizationProof` is typically a pair of ECDSA signatures for most wallets. Only the first signature is relevant for `_hookIsNewConfigAuthorized`. (The second signature is used for the `hookIsNewConfigValid`.)
+This hook is called before the configuration update is applied. It should verify that the caller is authorized to change the configuration. `authorizationProof is typically a pair of ECDSA signatures for most wallets. Only the first signature is relevant for `_hookIsNewConfigAuthorized`. (The second signature is used for the `hookIsNewConfigValid`.)
 
 If the signature is valid, the hook should return successfully. Otherwise, it should revert.
 

docs/pages/maintaining-wallets.mdx

@@ -9,12 +9,12 @@ Beyond adding and removing signers, cross-chain syncing introduces additional co
 
 ## Performing Wallet Upgrades
 
-A wallet's configuration is deeply intertwined with the implementation contract that reads that configuration. Upgrading a wallet's implementation alone could break if it could not read the existing configuration, and updating the configuration without upgrading the implementation could break if the new implementation expects a new configuration. Keyspace can help wallet vendors implement atomic upgrades that ensure both the configuration and the implementation are upgraded at the same time.
+A wallet's configuration is deeply intertwined with the implementation contract that reads that configuration. Upgrading a wallet's implementation alone could fail if it cannot read the existing configuration. Similarly, updating the configuration without upgrading the implementation may fail if the new implementation expects a different configuration. Keyspace can help wallet vendors implement atomic upgrades that ensure both the configuration and the implementation are upgraded at the same time.
 
 To do this, the implementation address for the wallet can be stored in the keystore configuration that is synced across chains. Your wallet's [`_hookApplyNewConfig`](/keystore-basics#_hookapplynewconfig) is responsible for detecting the new implementation address and performing the upgrade. This new implementation address needs to be deployed on each chain supported by the wallet or the wallet will not be usable on those chains after syncing.
 
 :::note
-If your wallet provides direct access to `upgradeTo` or the equivalent for your proxy contract, the implementation can be overwritten without using Keyspace, and since this change will not be synced, the user will end up with inconsistent behavior across chains. Without care, this could lead to unexpected behavior.
+If your wallet provides direct access to `upgradeTo` or the equivalent for your proxy contract, the implementation can be overwritten without using Keyspace, and since this change will not be synced, the user will end up with inconsistent behavior across chains. Without proper safeguards, this inconsistency could lead to unexpected behavior.
 :::
 
 ## New Chains and Wallet Factories
@@ -37,7 +37,7 @@ If cross-chain Merkle proofs have stopped working due to hard forks, another way
 
 #### Recovery Guardians
 
-Recovery guardians affect whether the wallet can be activated on a new chain. Recovery guardians are typically stateful: the recovery is initiated on a blockchain, then can only be processed after a delay that is verified by proving the elapsed time since the recovery was initiated. Since recovery guardians require external state to be verified, they are not guaranteed to always successfully re-execute as preconfirmations on new replica chains indefinitely.
+Recovery guardians affect whether the wallet can be activated on a new chain. Recovery guardians are typically stateful: the recovery is initiated on a blockchain, then can only be processed after a delay that is verified by proving the elapsed time since the recovery was initiated. Recovery guardians rely on external state, making their re-execution as preconfirmations on new replica chains unreliable.
 
 In the current version of Keyspace, the way to build a recovery guardian is to write it as a periphery contract that is added as a signer to the wallet. When the conditions for the guardian are met, it calls `setConfig` directly on the wallet. `_hookIsNewConfigAuthorized` can then check `msg.sender` to verify that the guardian's address is authorized in the wallet's configuration.
 

docs/pages/references.mdx

@@ -9,7 +9,7 @@ title: References
   * [Deeper dive on cross-L2 reading for wallets and other use cases](https://vitalik.eth.limo/general/2023/06/20/deeperdive.html), by Vitalik Buterin
   * [What kind of layer 3s make sense?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html), by Vitalik Buterin
   * [The Three Transitions](https://vitalik.eth.limo/general/2023/06/09/three_transitions.html), by Vitalik Buterin
-  * [Possible futures of the Ethereum protocol, part 2: The Surge](https://vitalik.eth.limo/general/2024/10/17/futures2.html), by Vitalik Buterin
+  * [Possible Futures of the Ethereum Protocol, Part 2: The Surge](https://vitalik.eth.limo/general/2024/10/17/futures2.html), by Vitalik Buterin
 * Other Perspectives on the Keystore Problem
   * [Keystore Rollup: Revolutionizing Smart Account Interoperability](https://safe.global/blog/keystore-rollup-smart-account-interoperability), by Lukas Schor & Safe
   * [Towards the wallet endgame with Keystore](https://scroll.io/blog/towards-the-wallet-endgame-with-keystore), by Dom, Ye Zhang, & Scroll

docs/pages/releases.mdx

@@ -14,7 +14,18 @@ Keyspace v0.1.0 is the first smart contract-based implementation of Keyspace. Th
 
 *June 18, 2024*
 
-The Dedicated Rollup Beta (v0.0.2) release of Keyspace introduces [`keyspace-client`](https://github.com/base-org/keyspace-client/tree/v0.0.2), an example TypeScript client for Keyspace with an integrated smart wallet, and [`keyspace-recovery-service`](https://github.com/base-org/keyspace-recovery-service/tree/v0.0.2), an RPC service for generating SNARK proofs of the signatures users sign to change their keys. The supported chains have been expanded from Base Sepolia and Optimism Sepolia to include Arbitrum Sepolia, Gnosis Chiado, Polygon Amoy, BSC Testnet, and Avalanche Fuji.
+The Dedicated Rollup Beta (v0.0.2) release of Keyspace introduces:
+- [`keyspace-client`](https://github.com/base-org/keyspace-client/tree/v0.0.2): TypeScript client for Keyspace with an integrated smart wallet.
+- [`keyspace-recovery-service`](https://github.com/base-org/keyspace-recovery-service/tree/v0.0.2): RPC service for generating SNARK proofs of the signatures users sign to change their keys.
+
+Supported chains have been expanded to include:
+- Base Sepolia
+- Optimism Sepolia
+- Arbitrum Sepolia
+- Gnosis Chiado
+- Polygon Amoy
+- BSC Testnet
+- Avalanche Fuji.
 
 ## Dedicated Rollup Alpha (v0.0.1)
 

docs/pages/revoking-signers.mdx

@@ -5,12 +5,12 @@ description: Learn how to safely revoke signers and handle compromised signer sc
 
 # Revoking Signers
 
-One of the hardest problems for cross-chain wallets is revoking compromised signers. Most cross-chain wallets have no single source of truth for the wallet's configuration, so revoking a compromised signer requires broadcasting the revocation across all active chains. Keyspace introduces the ability to sync configuration changes across chains, which is the first step towards making revoking compromised signers easier. However, there are still two avenues for a compromised signer to take control of a wallet:
+Revoking signers is a critical process in maintaining wallet security, especially in scenarios where a signer has been compromised. This process ensures that the compromised key cannot be used to access or control the wallet.
 
 1. The target replica chain is **actively** used by the wallet, so it has been synced, but using data from 3.5+ days ago due to the master chain's settlement delay.
 2. The target replica chain is **inactive** and has never been synced, so the configuration that contains the compromised signer is still valid on that chain, *no matter how much time has elapsed*. (This is not a Keyspace-specific issue: it's a problem for most cross-chain wallets.)
 
-Keyspace handles the first scenario by allowing you to preconfirm revocations on active chains. The second scenario is currently infeasible to mitigate, so wallet vendors must understand the implications of revocations on inactive chains.
+Keyspace handles the first scenario by allowing you to preconfirm revocations on active chains. The second scenario is currently difficult to mitigate, so wallet vendors must understand the implications of revocations on inactive chains.
 
 ## Preconfirming Revocations on Active Chains
 
@@ -42,4 +42,4 @@ Cost-effective syncing depends on cross-chain Merkle proofs, but these can break
 
 The top two paths for addressing this currently seem to be introducing EVM opcodes for direct cross-chain storage reads, or standardizing cross-chain Merkle proof validation contracts that are upgraded with each hard fork, just like the withdrawal and deposit bridges are. The [L1SLOAD opcode proposal](https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388) would eliminate the risk of L1 hard forks. L2 hard forks would require a similar opcode, either for a widely used master chain for keystores or for a dedicated rollup for keystores. Such a `KEYSTORESLOAD` opcode would eliminate the risk of L2 hard forks.
 
-Once one of these paths are viable, we expect to change our recommendation to require a recent sync even before preconfirmations can be used, which would limit the window of time that a compromised signer can be used to the eventual consistency period plus the settlement delay of the master chain.
+Once one of these paths is viable, we expect to change our recommendation to require a recent sync even before preconfirmations can be used, which would limit the window of time that a compromised signer can be used to the eventual consistency period plus the settlement delay of the master chain.