---
# System prepended metadata

title: 'Part 3: From Email to Smart Account — Implementing Social Login for DeFi'

---

# Part 3: From Email to Smart Account - Implementing Social Login for DCA Tool

In [Part 1](https://hackmd.io/@AHadzibabic/r1TiNN-Ree), we explored the landscape of key management, from hardware wallets and seed phrases to distributed cryptography and smart accounts. In [Part 2](https://hackmd.io/@AHadzibabic/BkwtG49Cge), we framed the architectural challenge of building a self-custodial DCA tool (where should vault logic live, and who controls it). We narrowed the design space to two approaches: Smart Account sessions and Programmable Key Pairs (PKPs).

Now it's time to get concrete. In this article, we'll walk through the implementation path we chose: **social login via Privy, combined with Rhinestone smart accounts**. This is the bridge that lets a user log in with an email and end up controlling a programmable smart account on-chain; no seed phrases, no wallet extensions, no friction.

## Why This Combination?

Recall from Part 2 that Smart Account sessions keep vault logic on-chain, with policies enforced by blockchain consensus. That's the security model we want for a DCA tool handling real funds.

But we also need onboarding to feel like any modern web app. Users shouldn't need to understand EOAs, gas, or key pairs. They should type their email, verify a code, and start investing.

That's where Privy comes in, it handles authentication and wallet creation behind the scenes, giving us an embedded signer that feeds directly into Rhinestone's smart account system.

## The Three Layers

The implementation chains three systems together:

1. **Privy** - authenticates the user and creates an embedded wallet
2. **wagmi** - a standard interface that makes that wallet usable by any dApp code
3. **Rhinestone SDK** - wraps the wallet as the owner of a programmable smart account

Let's trace the flow step by step.

## Step 1: Email OTP Creates an Embedded Wallet

When a user logs in, Privy handles the entire authentication flow (email, OTP, session). The key configuration is that Privy automatically creates an **embedded EOA wallet** for any user who doesn't already have one.

This wallet is created using **MPC (Multi-Party Computation)**. As we discussed in Part 1, distributed cryptography eliminates single points of failure. Privy applies this principle at the wallet level. The private key is split into shards, some stored on Privy's servers and some derived from the user's browser session. The full key is never stored whole in any single location.

The result: the user now has a real Ethereum EOA without ever seeing a private key or a seed phrase.

## Step 2: The Embedded Wallet Becomes a Standard Connector

Privy's wagmi adapter takes the embedded wallet and presents it to the application as a normal wallet connection, indistinguishable from MetaMask or any other browser wallet.

This matters because all existing dApp tooling works out of the box. The application calls standard wagmi hooks like `useAccount()` and `useWalletClient()`, unaware that the signer behind them is Privy's MPC system rather than a browser extension.

## Step 3: The EOA Becomes a Smart Account Owner

Here's where we connect back to the architecture from Part 2. The Rhinestone SDK takes the EOA from Step 2 and designates it as the **owner** of a smart account.

The smart account address is **deterministically derived** from the EOA. This means:

- Same email → same EOA (via Privy's MPC)
- Same EOA → same smart account (via Rhinestone)
- **Same email → same smart account, every time, on any device**

The smart account doesn't even need to exist on-chain until the first transaction, a pattern called **counterfactual deployment**. The address is known in advance, and the contract is deployed automatically when first needed.

## The Complete Chain

![image](https://hackmd.io/_uploads/rJjAhEVKZg.png)


```
  → Privy verifies identity (Email + OTP)
  → MPC reconstructs signing capability in the browser
  → Embedded EOA appears as a standard wagmi wallet
  → Rhinestone SDK wraps EOA as the smart account owner
  → EOA signs UserOperations
  → Smart account executes them on-chain
```

The user thinks they're logging into a web app. Under the hood, they're gaining control of a programmable smart account secured by blockchain consensus.

## Where Everything Lives

| Data | Location |
|------|----------|
| Email → EOA mapping | Privy's servers (managed by Privy) |
| MPC key shards | Split between Privy servers and user's browser |
| EOA → Smart account mapping | Deterministic (computed, not stored) |
| User positions & strategy data | Application database |
| Funds | On-chain in the smart account |

## Multi-Device Access

Since Privy manages the email-to-EOA mapping, a user can log in from any device with the same email. Privy reconstructs the same key shards, producing the same EOA, which maps to the same smart account. All funds and DCA positions are exactly where they left them.

## What's Next

With social login and smart account creation in place, we have the foundation: users can onboard with an email and control a programmable account on-chain. The next step is the core of what we set out to build, **the actual DCA execution logic**. How do session keys authorize automated swaps? How does the scheduler trigger trades while respecting user-defined rules? That's where we'll pick up in Part 4.

## References

- [Part 1: Key Management Approaches](https://hackmd.io/@AHadzibabic/r1TiNN-Ree)
- [Part 2: Designing a Self-Custodial DCA Tool](https://hackmd.io/@AHadzibabic/BkwtG49Cge)
- [Privy Documentation](https://docs.privy.io/)
- [Rhinestone SDK — Session Keys](https://docs.rhinestone.dev/home/concepts/session-keys)
- [ERC-4337: Account Abstraction](https://eips.ethereum.org/EIPS/eip-4337)