> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aeon.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Core SDK Flows

> Understand how AeonClient and AeonSigner SDKs work together for various operational flows.

## Aeon SDK: Operational Flows

This section describes how an application using the Aeon SDK (`AeonClient` and `AeonSigner`) automates interactions and operations.

### Operational Flows

**Creating a Workspace**

This is currently handled via the Aeon platform's frontend. We will expose an SDK interface for this in the future.

**Adding an API User**

1. Your application generates an EVM compatible private key and stores it securely.
2. In the Aeon platform's frontend, an administrator adds a User using the corresponding EVM address associated with the generated private key.
3. Upon approval of the config request in the frontend, a capability is associated with the EVM address, making it redeemable.
4. Your application initializes an `AeonSigner` instance with the EVM private key. (See [AeonSigner Constructor](./aeon-signer/constructor) for initialization).
5. Your application calls `aeonSigner.signAcceptWorkspaceMessage(workspaceId)` to generate a signature for the workspace invitation.
6. Then, your application calls `aeonClient.acceptWorkspaceInvite(signedMessage)` using the signature from the previous step. This queues the operation.
7. The transaction for accepting the invite is then executed by calling `aeonClient.build()` and then `aeonSigner.signAndExecuteAeonTx(txbFromBuild)`.
8. The end-user (owner of the workspace/keys) receives a request on their device to share their key shares with the AeonSigner's public key.
9. Once the user approves and shares, your application calls `aeonSigner.acceptPendingUserShares(workspaceId)` to detect, validate, and integrate these shares. (See [acceptPendingUserShares()](./aeon-signer/accept-pending-user-shares)).

**Setting Policies**

Policies are currently configured via the Aeon platform's frontend. The workspace can be configured to be immutable, ensuring that policies are not subsequently changed. We will expose an SDK interface for this in the future.

**Request Transaction**

Currently, requesting transactions requires simulation of the expected balance changes for simplicity. In the future, dApp specific integrations may be offered to avoid dependency on any centralized backend service.

1. **Define and Simulate Operations with `AeonClient`**:
   * Your application uses `AeonClient` to define one or more transaction operations.
   * Call methods `aeonClient.simulate("evm", params)`, `aeonClient.simulate("sui", params)`, for each part of the desired transaction. (See specific simulation docs under [AeonClient Request](./aeon-client/request/) for details).
   * The `AeonClient.build()` method is then called:
     ```typescript theme={null}
     const aeonClient = new AeonClient();
     // EVM transaction example
     aeonClient.simulate("evm", {
       chain: "ethereum",
       from: "0xSENDER_ADDRESS",
       to: "0xRECIPIENT_ADDRESS",
       value: "1000000000000000000", // 1 ETH in wei
       data: "0xCONTRACT_METHOD_CALL_DATA",
     });
     // Add other simulations if it's a batch
     const assembledTxData = await aeonClient.build();
     // assembledTxData contains balance changes and the unsigned transaction block (TXB)
     // prepared by the server, ready for local signing.
     ```
2. **Sign Locally with `AeonSigner` and Execute**:
   * The `assembledTxData.txb` (the unsigned transaction block) is passed to `AeonSigner`.
   * `AeonSigner` signs the TXB (`await aeonSigner.signAndExecuteAeonTx(txb)`). The signed TXB is sent to Aeon's backend for gas sponsoring and execution.

**Voting**

If the transaction matches a policy that requires approval from other users, this is handled manually through the standard Aeon platform interfaces. The SDKs will provide methods for automated voting participation in the future.

**Sign Transaction**

After a transaction proposal or intent is approved (either autoapprved or by going through voting), the transaction can be signed and executed.

1. **Prepare Transaction with `AeonClient` for Server-Side Adjustments**:
   * Your application uses `AeonClient` to request signing preparation for a specific chain, for example, `aeonClient.prepareTransactionForSigning(params)`.
   * The `AeonClient.build()` method is called. The backend service performs these actions:
     * Estimates gas fees.
     * Gets the correct nonce (if applicable).
     * Performs other necessary preparations based on the chain.
     * Returns a serialized, unsigned transaction ready for signing.
     ```typescript theme={null}
     // Example for preparing an EVM transaction
     // const preparedTx = await aeonClient.prepareTransactionForSigning({
     //   type: "evm",
     //   details: { /* minimal EVM transaction details */ }
     // });
     // // 'preparedTx.unsignedTxb' would be passed to AeonSigner
     ```
2. **Sign prepareSigning Aeon Tx Locally with `AeonSigner` and Execute**:
   * The `assembledTxData.txb` (the unsigned transaction block) is passed to `AeonSigner`.
   * `AeonSigner` signs the TXB (`await aeonSigner.signAndExecuteAeonTx(txb)`). The signed TXB is sent to Aeon's backend for gas sponsoring and execution.
3. **MPC signing**:
   * The `AeonSigner` participates in the distributed signature generation process using its locally managed key share.
   * Your application calls `aeonSigner.signWithUserShare(hashedMessages_b64, signatureScheme)`. (See [`signWithUserShare()`](./aeon-signer/sign-with-user-share) for more details).
   * The method returns the user's signature contribution (`signature_b64`).
   * After signing is completed, the resulting signature is broadcast on the Ika network, is picked up by our backend service and submitted to chain. We will add a guide in the future how to host this relay yourself.