What Otomato Can (and Can’t) Do with User Funds

What Otomato Can (and Can’t) Do with User Funds

1. We Never Take Custody

Otomato is 100% self-custodial. We never have access to your funds or your private keys.

However, in order to automate your actions, you need to explicitly approve what we’re allowed to do—no more, no less. Each automation is strictly limited to the actions you authorized.


2. What Otomato Can Do (Technically)

When you use Otomato to build an automation that requires on-chain actions (i.e. transactions), you authorize us to perform those specific actions you approved. That means that Otomato can now:

  • Call specific smart contract functions linked to what you specifically want to automate (like deposit() or swap())

  • Only on specific protocols you specify (like Aave or Compound)

  • Only with the specific tokens you specify (like USDC)

Please note that when we say "you approve" actions, it means you cryptographically sign them using your wallet. This signature, based on your private key, makes it technically impossible for Otomato to forge or lie about your authorization.

We cannot:

  • Transfer your funds to any wallet

  • Call any unapproved function

  • Go beyond what you explicitly allow

Our system is built on top of ERC-4337 session keys, function selectors, and call policies, which strictly enforce these boundaries. You can learn more about how it works technically in this document:

Security, security & security


Example use cases & associated risks

3. Example Use Case: Lending Aggregator

Let’s say you build an automation to optimize your USDC lending yield between Aave and Compound. You will need to approve us to perform exactly four actions:

  • Deposit USDC into Aave

  • Withdraw USDC from Aave

  • Deposit USDC into Compound

  • Withdraw USDC from Compound

That’s it. No other action is possible.

Whenever the yield is better on one protocol, we:

  • Withdraw from the current one

  • Deposit into the better one

We can’t transfer your funds, touch your wallet, or do anything else.

🔒 Risk?

The only risk we add (on top of the existing blockchain risks you would encounter if doing the operations manually) is executing your actions at the wrong time. For example:

  • Switching protocols when yields aren’t actually better


4. Example Use Case: DCA Bitcoin

You set up a Daily Buy automation to convert USDC to BTC.

You allow us to:

  • Swap USDC → BTC We cannot:

  • Swap BTC back to USDC

  • Transfer your USDC or BTC elsewhere

Again, the only added risk is executing the swap at a suboptimal time (e.g., missing the daily window or executing at a poor price).


5. What About Conditional Automations?

If you tell us: “Sell BTC if the price goes above \$60,000”, we can execute the sell action only when the condition is met.

The only risk? We might misread the timing:

  • Sell at the wrong time

  • Or fail to execute when you expect it

But we still can’t steal your funds.


6. Mitigation: Ensuring We Can’t Lie

We’re exploring ways to prove we executed actions only when your conditions were true—even to regulators or auditors. Potential solutions:

  • Decentralized execution nodes

  • Trusted Execution Environments (TEEs) or Zero-Knowledge Proofs to verify execution integrity

  • Human in the loop (the user actually is prompted to approve the on-chain actions when the automation gets triggered).

These are not our focus today, as they don’t directly improve the user experience (except human in the loop), but we’ll adopt them if they become necessary to operate legally.


7. Important Final Note

Everything above applies only to on-chain automations (actual blockchain transactions). Features like:

  • Notifications

  • AI-based decisions with human in the loop

  • Web2 integrations

don’t require funds access permissions and operate more like a classic web2 SaaS business.

Last updated