SatsPilot

"Tu copiloto cripto en WhatsApp." — DCA into Bitcoin from WhatsApp on Rootstock, with zero-slippage DOC→RBTC conversion via Money on Chain and automatic yield on the idle balance.

Built for the Vendimia Hackathon. The premise: most LATAM users don't have MetaMask, can't read smart contract addresses, and won't connect a wallet to a website they don't know — but everyone has WhatsApp. So make the entire DCA flow a WhatsApp conversation. No wallet UI. No web3 onboarding. No bridges.

Repo

github.com/LucianoLupo/crypto-vendimia-hackathon

What it does

1. You send a WhatsApp message: "Quiero invertir 5 dólares en bitcoin cada semana".
2. The bot parses your intent — local regex first, falling back to Claude 3.5 Haiku via OpenRouter for free-form Spanish/English.
3. It creates a DCA schedule that runs at the cadence you picked.
4. Each execution converts DOC (the BTC-collateralized stablecoin native to Rootstock) into RBTC via Money on Chain's redeemFreeDoc() — at the oracle price, with zero slippage.
5. While DOC sits idle waiting for the next purchase, it earns ~5% APY in Tropykus kDOC.
6. Smart DCA: the bot compares spot to a 7-day SMA (CoinGecko) and adjusts the buy amount ±50% — buy more on dips, less on tops.

Architecture

WhatsApp user
    │  "comprar 10 RBTC diario"
    ▼
Kapso.ai (WhatsApp Cloud API wrapper) ── HMAC-signed webhook
    │
    ▼
SatsPilot backend (Node.js / TypeScript — "keeper" role)
    │  Intent parser → command router → contract calls
    ▼
SatsPilotDCA.sol (Rootstock smart contract)
    ├── Tropykus kDOC ── DOC idle yield ~5% APY
    ├── Money on Chain ── redeemFreeDoc()  (oracle, 0 slippage)
    └── Tropykus kRBTC ── purchased RBTC keeps earning yield
        │
        ▼
    Rootstock (EVM sidechain secured by Bitcoin's hashrate)

Smart contract

The DCA logic — schedules, deposits, withdrawals, executions, fees — all lives in SatsPilotDCA.sol. The user's funds sit in the contract; the keeper can only call executeDca(user) when a schedule is due. Users withdraw directly via withdrawDoc / withdrawRbtc / cancelSchedule.

Status: deployed on RSK testnet at 0xFB7C51D09Da311204d9eCA7791c3C7A47d0E2A4c. Mainnet deploy pending. Not audited — hackathon code, don't deposit real money yet.

Why no DEX swap? RSK Uniswap V3 forks have thin liquidity for DOC/RBTC, so any non-trivial DCA size eats slippage. Money on Chain's redeemFreeDoc() redeems DOC against the protocol's BTC reserves at the oracle price — same primitive that backs DOC's $1 peg — so the conversion is essentially gas + a 0.15% MoC fee. No DEX, no MEV, no slippage.

What I'd do differently for production

The honest part of this project is the custody model. A WhatsApp interface means the backend has to sign on the user's behalf using HD-derived wallets — which makes the signing layer custodial even though the DCA logic is verifiable on-chain. To get to truly non-custodial:

• ERC-4337 session keys scoped to "execute DCA only", or
• A small companion mobile app where the user signs from their own wallet and the keeper just nudges the contract, or
• A Rootstock-native wallet integration (Beexo) that signs from the phone.

Any of those collapses the trust surface to "the contract logic" instead of "the contract logic plus the keeper's mnemonic." For the hackathon, the hybrid model was the right tradeoff between UX and decentralization.

Connection points

• The "agent-native API surface" idea here (Kapso webhook → intent parser → on-chain execution) shares a lineage with the agent skills I keep building — agent-orchestrator, Rug Scanner — where the human sends intent and the system handles execution.
• LATAM positioning matches the broader thread of building tools for the Argentinian / Spanish-speaking crypto user that don't assume MetaMask literacy.