Contexte et motivations
Depuis 2019, Polymarket s’appuyait sur le Gnosis Conditional Tokens Framework (CTF). Chaque nouvelle fonctionnalité ajoutait une couche de contrats, ce qui augmentait la surface d’attaque et le coût en gaz pour les utilisateurs. Le besoin d’une architecture plus simple et plus économique a conduit l’équipe à concevoir Protocol V2, une refonte complète du stack.
Architecture du nouveau protocole
V2 regroupe l’ensemble des fonctions de marché dans un seul contrat ERC1155 dédié aux positions. Ce contrat gère les tokens représentant les issues possibles, ce qui élimine les appels inter‑contrats fréquents du CTF. En parallèle, un token de collatéral pUSD centralise les fonds, tandis qu’un échange et un routeur uniques orchestrent les transactions. La consolidation réduit le nombre d’appels de contrat de plusieurs dizaines à une poignée, ce qui diminue le gas consommé par transaction et simplifie la logique de validation.
Mécanismes d’oracle et de bridging
Le OracleAggregator introduit une couche d’abstraction permettant de brancher plusieurs sources de données : UMA, Chainlink et, à terme, d’autres oracles. Chaque module de résolution est interchangeable, ce qui limite la dépendance à un seul fournisseur et améliore la résilience face à des pannes d’oracle. Le protocole intègre également un support natif de bridging pour les positions, le collatéral et les résolutions, ouvrant la voie à une expansion multi‑chaîne. Cette approche repose sur des contrats de pont standardisés qui verrouillent les actifs sur la chaîne source avant de les libérer sur la destination, assurant l’intégrité des soldes.
Implications et limites
La migration vers un contrat ERC1155 unique simplifie la maintenance et facilite les audits, mais elle concentre également le risque : une faille dans le contrat principal pourrait affecter l’ensemble du système. Le choix du token pUSD comme collatéral implique une dépendance à la stabilité de ce stablecoin ; toute perte de confiance pourrait entraîner des liquidations massives. Le modèle d’upgradeabilité, géré par un processus de gouvernance, permet d’ajouter des fonctionnalités sans interrompre le service, mais il expose le protocole à des attaques de gouvernance si les votes sont mal sécurisés. Enfin, le support multi‑chaîne reste conditionné à la disponibilité de ponts fiables ; des vulnérabilités dans ces ponts pourraient être exploitées pour voler des positions ou du collatéral.
