Skip to main content

​
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 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()).
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 for details).
    • The AeonClient.build() method is then called: 
      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.
      // 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() 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.