TBD

The following are some limitations and ideas we are still exploring.

Sending Transactions

We are still figuring out how to securely send transactions from handlers. The execution will still be centralized, so sending transactions through Kyn handlers should not be used for critical functionality unless there are on-chain checks that prevent Kyn from acting maliciously. A few options we've considered: - Storing encrypted private keys as metadata that can be passed to handler functions. - Integrating with existing key stores, and abstracting the integration at the Solidity level. - The user could generate deterministic addresses for contracts that are deployed upon sending transactions, which perform on-chain checks that the user specifies when developing the handler.

Monetization and Gas Costs

We've considered a few ideas for how to monetize the platform. As handlers are ran on an EVM, we could use gas as a measure for how much to charge users for handler executions. We could try different limits such as charging per-execution, consuming credits that users purchase before registering handlers, or limiting the maximum amount of gas a handler function is allowed to consume depending on the user's plan.

If we want to provide a feature in which we submit transactions from wallets fully managed by Kyn, we could refund gas to ourselves from a pre-funded wallet that we generate for each user. This could be made automatically within each transaction that is sent from a handler function.

Execution environment isolation

Since handlers are executed within the Foundry Virtual Machine there are certain security concerns. Specifically, there's a risk that handlers could be used inappropriately, such as employing Foundry's ffi cheatcodes to execute unrestricted commands or initiating unauthorized requests to internal services. These actions could potentially compromise the integrity and security of the system.

To mitigate these risks, we are considering the implementation of custom cheatcodes. These specialized cheatcodes would be designed to be more restrictive compared to standard ones, effectively limiting the scope of actions that users can perform through handlers. This approach ensures that while the handlers retain their powerful functionality, they do so within a controlled and secure environment.

Modifying/forking Handlers

Even though we plan to support parameterized clones right away, another feature we could provide is to fork handlers and allow users to not only modify parameters but also modify the contract sources. This would need an in-app editor. On the other hand, if a handler is public and available on platforms such as GitHub, it might be simpler to just fork the git repository to achieve pretty much the same result.

Git integration

Related to the previous section, it might be worth it to integrate with GitHub in some way. For example, creating a handler through Kyn's web app by simply selecting a github repository.