Implementation Plans

This document outlines viable approaches for implementing automatic loan repayment deduction from merchant revenue sources (Stripe, Square, etc.).


Current Architecture (Phase 1)

Status: Non-custodial with centralized triggers

Merchant Revenue β†’ Backend Calculates β†’ Bridge Converts β†’ Smart Contract β†’
CDP Wallet Validates Session Key β†’ Auto-Approves β†’ Repayment Complete

Trust Model

  • βœ… Non-Custodial: User controls keys via CDP smart wallet

  • βœ… Session Limits: On-chain enforcement of max amounts

  • ⚠️ Centralized Calculation: Backend trusted for revenue data

  • ⚠️ Web2 Data Source: Stripe/Square webhooks (off-chain)


Phase 2: Viable Auto-Deduction Plans

Best for: Production deployment with decentralized triggers

Architecture

Replace centralized backend with Chainlink Keeper network that automatically checks for repayment conditions.

Revenue Oracle Integration

Backend (Off-Chain Oracle Worker)

Benefits

βœ… Decentralized trigger mechanism (Chainlink Keeper network) βœ… Transparent revenue data on-chain βœ… Multiple oracle operators can submit data (reduces single point of failure) βœ… Auto-executes when conditions met

Drawbacks

⚠️ Still requires trusted oracle for Stripe data ⚠️ Oracle operator can submit false revenue data ⚠️ Gas costs for Chainlink upkeep

Cost Estimate

  • Chainlink Automation: ~$5-20/month depending on check frequency

  • Oracle submissions: ~$1-5 per submission (hourly = ~$150/month)


Plan B: Multi-Signature Backend Control

Best for: MVP with enhanced security and transparency

Architecture

Backend proposes repayments, but requires multiple signatures to execute.

Backend Integration

Auditor Dashboard

Benefits

βœ… Transparent on-chain proposal system βœ… Multiple parties verify calculations βœ… Borrower can approve/reject βœ… Auditor adds independent verification βœ… All data logged on-chain

Drawbacks

⚠️ Slower (requires multiple signatures) ⚠️ Still requires trusted backend and auditor ⚠️ More gas costs (multiple transactions)


Plan C: On-Chain Revenue Attestations

Best for: High-trust merchants willing to self-report

Architecture

Merchants submit signed revenue statements directly on-chain.

Stripe Integration (Hypothetical)

Benefits

βœ… Fully on-chain revenue data βœ… Cryptographically verified by Stripe βœ… No backend needed βœ… Maximum transparency

Drawbacks

❌ Stripe doesn't support this (deal-breaker for now) ❌ Would require partnership with Stripe/Square ❌ Merchants must manually submit (friction)


Plan D: Crypto-Native Revenue (Full Decentralization)

Best for: Merchants accepting crypto payments only

Architecture

Merchant's smart wallet automatically splits incoming payments.

Benefits

βœ… Fully trustless - no backend, no oracle βœ… Instant - repayment on every sale βœ… Transparent - all on-chain βœ… No gas for borrower - customer pays gas

Drawbacks

❌ Only works for crypto-native merchants ❌ Doesn't integrate with Stripe/Square ❌ Customers must have crypto wallets


Comparison Matrix

Plan
Decentralization
Stripe Integration
Gas Costs
Implementation Complexity
Best For

A: Chainlink

⭐⭐⭐⭐

βœ… Via Oracle

Medium

High

Production

B: Multi-Sig

⭐⭐⭐

βœ… Direct

Medium

Medium

MVP with security

C: Attestations

⭐⭐⭐⭐⭐

❌ Not supported

Low

Blocked

Future (if Stripe adds)

D: Crypto-Native

⭐⭐⭐⭐⭐

❌ N/A

Low

Low

Crypto-only merchants


Phase 2A: Multi-Sig Backend (Months 1-3)

Why: Quick to implement, adds transparency and security

  1. Deploy multi-sig contract

  2. Onboard independent auditor

  3. Build auditor dashboard

  4. Enable borrower approval/rejection

Why: Decentralized triggers, production-ready

  1. Build Stripe Oracle contract

  2. Set up Chainlink Automation

  3. Deploy oracle worker (off-chain)

  4. Migrate from multi-sig to Chainlink

Phase 2C: Hybrid Approach (Months 7+)

Why: Best of both worlds

  1. Chainlink for automatic triggers

  2. Multi-sig for large repayments (>$1K)

  3. Crypto-native option for crypto merchants

  4. Dispute mechanism for borrowers


Trust Minimization Strategy

Even with centralized components, you can minimize trust:

1. Transparent Logging

2. Dispute Mechanism

3. Rate Limiting

4. Emergency Stop


Conclusion

For Phase 2, we recommend:

  1. Start with Plan B (Multi-Sig) for immediate security improvements

  2. Transition to Plan A (Chainlink) for decentralized triggers

  3. Keep Plan D (Crypto-Native) as option for crypto merchants

  4. Monitor Plan C (Attestations) in case Stripe adds support

All plans maintain non-custodial architecture while improving decentralization of revenue verification and repayment triggers.

Last updated