In the [previous article](https://t.co/xpYCru6vsd), we explored different approaches to **key management**, from hardware wallets to distributed cryptography and smart accounts. Each solution defines how users hold, recover, and secure their keys. But key custody is only half the story.

The next challenge is **interaction**: how do we let users engage with DeFi apps seamlessly, without compromising self-custody or security?

In this article, we’ll tackle that question through a practical example: building a **self-custodial DCA (Dollar-Cost Averaging) tool** for everyday investing. Along the way, we’ll examine how different architectures shape both the security model and user experience.
### From Keys to Actions: The UX Challenge
Take **Tangem**, for example, a hardware-based wallet that removes seed phrases. To interact with a DeFi app, a user connects their Tangem mobile wallet just like any browser-based self-custodial wallet.
It’s secure, but not ideal for automation.

A **DCA (Dollar-Cost Averaging)** tool needs to:
- allow users to set an investment interval, and
- automatically execute trades on their behalf.

This introduces a new challenge:

> How can the app act **autonomously** while keeping the user in **full control** of their funds?

To achieve this, we can imagine a **DCA vault** that holds the user’s funds and investment logic. The user deposits tokens into the vault, and a scheduler triggers swaps on Uniswap (or similar DEXs) at specified intervals, but **only** according to the user’s defined rules.


That brings us to two key architectural questions:
### 1. Where is the vault logic located?
There are two broad options:
- **On-chain:**
- The vault is implemented as a **smart contract**.
- Logic and rules are enforced transparently on-chain (e.g. using Safe modules or custom DCA contracts).
- The scheduler only triggers swaps using an **authorized session keys** (e.g. [Rhinestone](https://docs.rhinestone.dev/home/concepts/session-keys#session-keys)), if all conditions (like timestamp, asset pair, limits) pass.
- **Off-chain:**
- The vault logic runs on external infrastructure — either a centralized server or a **distributed execution network** like [Lit Protocol](https://developer.litprotocol.com/) or [Chainlink CRE](https://chain.link/chainlink-runtime-environment).
- In this model, private keys (or key shares) sign transactions according to defined policies, and the execution environment enforces the rules.
### 2. Who controls the vault?
There are also two control models:
- **User-controlled:**
- The user maintains custody, while granting the app limited access via **session keys** or **Programmable Key Pairs (PKPs)**.
- Policies like spending caps or whitelisted functions are enforced either on-chain (Smart Account sessions) or off-chain (Lit network).
- **App-controlled:**
- The vault belongs to the app. The app has direct access to funds and executes actions on behalf of the user (similar to centralized solutions like [Calculated Finance](https://calculated.fi/)).
- This model sacrifices full self-custody for simplicity.

With those two questions in mind, the design space narrows to two main approaches: **Smart Account sessions** or **PKPs** (generated via Distributed Key Generation).
## Smart account sessions vs PKPs

Both **Smart Account sessions** and **PKPs (Programmable Key Pairs)** provide ways to delegate control securely, but they differ in **where logic is executed** and **who enforces policies**.

| Aspect | Smart Account Sessions | PKPs (Lit Network) |
| ------------------------ | ---------------------------------- | ----------------------------------------- |
| **Vault Logic Location** | On-chain (smart contract) | Off-chain (Lit distributed network) |
| **Control** | User-owned smart account | User-linked key pair managed by Lit nodes |
| **Policy Enforcement** | Enforced by blockchain consensus | Enforced by Lit Network consensus |
| **Recovery** | Managed via smart account recovery | Managed via linked authentication methods |

**Key differences:**
- **Smart Account Sessions:** Vault logic runs **on-chain**, secured by blockchain consensus. All rules are verifiable and immutable, and any DCA trades triggered by a session key are enforced directly by the smart contract. Updates or changes require contract upgrades.
- **PKPs via Lit Network:** Vault logic runs **off-chain** on the Lit distributed network. Trades still execute on-chain, but the rules are enforced by **Lit node consensus** instead of blockchain consensus. This allows more flexible automation and smoother UX while retaining user control via the programmable key pair.

the main distinction is where the **vault logic resides** and which consensus guarantees policy enforcement (blockchain vs Lit Network) while the DeFi interactions themselves remain on-chain in both cases.
## Conclusion
Building a self-custodial DCA tool highlights the delicate balance between **security, control, and user experience**. Smart Account sessions and PKPs both enable autonomous, rule-driven execution, but differ in **where vault logic lives** and **who enforces it**. Ultimately, the choice comes down to the trade-off your product prioritizes: **absolute on-chain security** or **efficient, user-friendly automation**, while still keeping funds in the user’s control. Understanding this distinction is **essential** to designing the next generation of self-custodial DeFi tools.

## Reference
- https://hackmd.io/@AHadzibabic/r1TiNN-Ree
- https://developer.litprotocol.com/
- https://docs.rhinestone.dev/home/concepts/session-keys#session-keys