Construire un bot de prêt Bitfinex en Python

Ce que nous allons construire

Un bot qui surveille le marché du financement USD, maintient une offre au repos 10% au-dessus du Flash Return Rate (FRR) actuel, et laisse la demande des emprunteurs venir à lui. Ce comportement unique — toujours laisser une offre au repos au-dessus du marché — est le cœur de la plupart des stratégies de financement, parce que les pics de taux sont trop courts pour être poursuivis manuellement.

Prérequis : Python 3.10+, pip install requests, un compte Bitfinex et $150+ dans le portefeuille de financement (le minimum par offre imposé par la plateforme). Tout le reste est ci-dessous.

Étape 0 : une clé qui ne peut pas vous faire de mal

Créez la clé API sur Bitfinex (API Keys → Create New Key) avec exactement ces permissions : Margin Funding read + write, Wallets read, Account Info read. Laissez les retraits et le trading désactivés — un bot de prêt n’en a jamais besoin, et une clé restreinte signifie qu’une clé compromise peut mal tarifer vos prêts mais ne peut pas vider votre compte.

Le détail permission par permission se trouve dans notre guide de l’API Bitfinex pour les prêteurs ; en version courte, tout ce qui figure dans cet article fonctionne avec les permissions ci-dessus et rien de plus.

Étape 1 : lire le marché (aucune clé requise)

Les taux sont publics. Le ticker de financement renvoie le FRR sous forme de taux quotidien à l’indice 0 — multipliez par 365 pour l’APR. Cette boucle est les yeux du bot :

Lancez-la et vous disposez d’un flux de taux en direct. Deux conventions à intérioriser dès maintenant : chaque taux Bitfinex est quotidien (0.0003 ≈ 10.95% APR), et chaque taux est brut — la plateforme conserve 15% des intérêts gagnés, multipliez donc par 0.85 pour obtenir ce qui atterrit dans votre portefeuille.

                
                  import requests, time

PUB = "https://api-pub.bitfinex.com"

def frr_apr(symbol: str = "fUSD") -> float:
    ticker = requests.get(f"{PUB}/v2/ticker/{symbol}", timeout=10).json()
    return ticker[0] * 365 * 100  # index 0 = FRR, a daily rate

while True:
    print(f"FRR now: {frr_apr():.2f}% APR")
    time.sleep(300)  # poll every 5 minutes — stay well inside rate limits
                
              

Étape 2 : placer une offre signée

Les écritures exigent une authentification : HMAC-SHA384 sur le chemin, un nonce strictement croissant, et le corps JSON. Voici toute la couche d’authentification — aucun SDK requis :

Le period est la durée du prêt en jours (2–120). Les durées courtes vous gardent liquide ; les longues verrouillent le taux. Le montant est une chaîne de caractères, minimum l’équivalent de $150. Si vous obtenez une erreur nonce: small, un autre processus a utilisé la clé — une clé par processus, toujours.

                
                  import hashlib, hmac, json, time, requests

KEY, SECRET = "your-key", "your-secret"
BASE = "https://api.bitfinex.com"

def auth_post(path: str, body: dict):
    nonce = str(int(time.time() * 1_000_000))  # must strictly increase per key
    raw = f"/api/{path}{nonce}{json.dumps(body)}"
    sig = hmac.new(SECRET.encode(), raw.encode(), hashlib.sha384).hexdigest()
    return requests.post(f"{BASE}/{path}", data=json.dumps(body), timeout=15, headers={
        "bfx-nonce": nonce, "bfx-apikey": KEY, "bfx-signature": sig,
        "content-type": "application/json",
    }).json()

def place_offer(rate_daily: float, amount: str = "150", period: int = 2):
    return auth_post("v2/auth/w/funding/offer/submit", {
        "type": "LIMIT", "symbol": "fUSD",
        "amount": amount, "rate": f"{rate_daily:.8f}", "period": period,
    })
                
              

Étape 3 : la boucle de stratégie

Voici maintenant le bot proprement dit : si rien n’est au repos, placez une offre 10% au-dessus du FRR actuel et attendez. La demande des emprunteurs la remplit lors des poussées de taux ; sinon elle reste en place. C’est une version grossière d’un plancher en percentile — une majoration fixe au lieu d’une majoration consciente du régime :

Voilà un bot de prêt fonctionnel. Il gagnera véritablement des intérêts de financement, et pendant les semaines calmes il ne vous fera pas honte. Il est aussi, délibérément, le début de l’histoire plutôt que sa fin.

                
                  def tick():
    apr = frr_apr()
    # naive floor strategy: rest 10% above the current FRR and wait to be hit
    target_daily = (apr * 1.10) / 365 / 100
    offers = auth_post("v2/auth/r/funding/offers/fUSD", {})
    if not offers:                      # nothing resting -> place one
        place_offer(target_daily)
    # a real bot also reprices stale offers, sizes per wallet balance,
    # handles partial fills, retries 429s, and survives restarts

while True:
    tick()
    time.sleep(600)
                
              

Ce que ces 60 lignes ne font pas

La liste honnête — chaque point est l’endroit où les bots amateurs meurent en silence :

• La stratégie. « FRR + 10% » est arbitraire. Le plancher devrait-il être le 96e percentile des 60 derniers jours ? Faut-il verrouiller 120 jours quand les taux sont hauts pour leur régime ? Bien répondre exige de rejouer des règles contre des années de données — c’est la différence entre un script et une stratégie.
• Le repricing. Une offre au repos devient obsolète à mesure que le marché bouge. Les bots de production retarifent en continu contre le carnet actuel sans faire fuir les exécutions.
• L’état et les redémarrages. Un crash au milieu de la boucle, puis un redémarrage : quelles offres sont les vôtres ? Qu’est-ce qui s’est rempli pendant votre absence ? Réconcilier l’état de la plateforme avec l’intention constitue l’essentiel du code d’un vrai bot.
• La gestion des pannes. Limites de débit 429, réponses 5xx, coupures WebSocket, collisions de nonce, exécutions partielles, prêts remboursés par anticipation — chacun exige une décision, pas une exception non gérée à 3 heures du matin.
• La comptabilité. Votre rendement réel vit dans le grand livre (crédits d’intérêts moins la commission de 15%), pas dans le taux que vous avez proposé. Réconcilier les écritures du grand livre paiement par paiement est ce qui rend réels les chiffres de gains et d’impôts.

FAQ du tutoriel