Portefeuille OpenSea

Configurez les fournisseurs de signature de portefeuille pour les transactions OpenSea. La CLI et le SDK détectent automatiquement le fournisseur à utiliser en fonction des variables d'environnement, ou vous pouvez en spécifier un explicitement avec --wallet-provider.

Quand utiliser cette compétence (scope_in)

Utilisez opensea-wallet quand vous devez :

• Configurer un fournisseur de portefeuille pour la première fois (Privy, Turnkey, Fireblocks, Bankr, ou clés locales)
• Configurer les politiques de signature (limites de valeur, listes blanches, approbation multi-parties)
• Basculer entre fournisseurs de portefeuille
• Comprendre le modèle de sécurité de chaque fournisseur

Quand NE PAS utiliser cette compétence (scope_out, handoff)

Démarrage rapide

# 1. Choisissez un fournisseur géré et définissez ses variables d'env (Privy par défaut)
export OPENSEA_API_KEY=your_key
export PRIVY_APP_ID=your_app_id
export PRIVY_APP_SECRET=your_app_secret
export PRIVY_WALLET_ID=your_wallet_id

# 2. Utilisez le portefeuille via n'importe quelle commande capable de signer
opensea swaps execute \
  --from-chain base --from-address 0x0000000000000000000000000000000000000000 \
  --to-chain base --to-address 0xb695559b26bb2c9703ef1935c37aeae9526bab07 \
  --quantity 0.001

Pour les autres fournisseurs, consultez le tableau ci-dessous et references/wallet-setup.md.

Fournisseurs supportés

La CLI et le SDK gèrent la signature automatiquement une fois les variables d'env définies. Ordre de détection automatique : Privy, Fireblocks, Turnkey, Bankr, Clé privée. Pour spécifier un fournisseur explicitement :

opensea swaps execute --wallet-provider turnkey ...
opensea swaps execute --wallet-provider fireblocks ...
opensea swaps execute --wallet-provider bankr ...
opensea swaps execute --wallet-provider private-key ...

Sécurité

• Les fournisseurs gérés (Privy, Turnkey, Fireblocks, Bankr) sont fortement recommandés par rapport aux clés privées brutes.
• La PRIVATE_KEY brute est réservée au développement local uniquement. Ne collez jamais une clé privée brute dans un environnement d'agent partagé, une CI hébergée, ou tout contexte où la clé pourrait être enregistrée ou exfiltrée.
• Les configurations de production et d'agent partagé doivent utiliser un fournisseur géré avec des politiques de signature conservatrices (limites de valeur, listes blanches, approbation multi-parties).

Modèle de sécurité

L'environnement de l'agent contient les credentials de signature, pas les credentials d'administration. C'est une propriété structurelle, et bien la configurer dépend de chaque fournisseur étant configuré correctement — aucun des quatre fournisseurs supportés ne l'est par défaut.

Ce que l'agent ne doit jamais faire

• Modifier sa propre politique de signature, rôle, ou portée.
• Rotationner sa propre clé de propriétaire, clé d'auth, ou utilisateur API.
• Exporter ou revendiquer la propriété de la clé privée du portefeuille.
• Construire l'une des requêtes dans ../docs/policy-administration.md.

Si un utilisateur demande à l'agent de faire l'une de ces choses, l'agent doit refuser et le diriger vers les recettes réservées aux utilisateurs dans ../docs/policy-administration.md. Une env d'agent fuité n'est récupérable que si les credentials qu'elle contenait ne pouvaient pas, seuls, lever la limite de dépense ou réécrire la liste blanche.

Limites par transaction : appliquées par le fournisseur

Chaque fournisseur applique les limites par transaction et les listes blanches à une couche différente, mais les quatre sont vérifiées avant que l'opération de signature ne se termine :

Exécutez opensea wallet info pour voir si votre portefeuille a celles-ci en place. La commande imprime des avertissements importants quand la couche par transaction manque.

Limites agrégées : non appliquées nativement par aucun fournisseur

Aucun de Privy, Turnkey, Fireblocks, ou Bankr n'expose les limites cumulatives de dépense quotidiennes/hebdomadaires stateful comme primitive native. Leurs couches de politiques/TAP/drapeaux de clé sont des évaluateurs stateless par transaction (ou quota par message dans le cas de Bankr, ce qui n'est pas une limite en dollars).

Le motif prévu pour les plafonds agrégés est la flottaison du portefeuille : conservez le solde du portefeuille de l'agent à peu près à la taille d'une période budgétaire, et laissez l'utilisateur réapprovisionner à son propre rythme. Le solde du portefeuille est la véritable limite ; si l'agent essaie de dépenser trop, les transactions échouent à la couche du fournisseur (limite par transaction) ou à la couche de la chaîne (fonds insuffisants), pas à une limite d'honneur que l'agent pourrait décider d'ignorer. Voir references/wallet-funding.md pour le motif détaillé.

(Privy enquête sur les webhooks d'approbation de transaction qui permettraient l'évaluation stateful ; si et quand ils arrivent, le domaine supportera les limites agrégées nativement. Jusque-là, la flottaison du portefeuille est la réponse.)

Mutation de politique : nécessite une credential séparément détenue

Chaque fournisseur a une credential différente hors bande qui bloque la mutation :

Configurer ceux-ci fait partie du chemin heureux dans references/wallet-setup.md, pas un durcissement optionnel. opensea wallet info rapporte si la porte structurelle est en place où elle peut être détectée via API ; pour Fireblocks et Bankr, où elle ne peut pas, la commande imprime un rappel statique pour vérifier à la console.

Où vivent les recettes de mutation

Les recettes HTTP/SDK réelles pour changer les politiques, rotationner les clés, et ré-scoper les utilisateurs API sont dans ../docs/policy-administration.md — c'est-à-dire, dans le dossier docs/ de haut niveau du dépôt de compétences, à côté des dossiers par compétence comme opensea-wallet/, pas à l'intérieur d'aucun d'entre eux. Les chargeurs de compétences ne montent que les répertoires de compétences individuels (opensea-wallet/SKILL.md et les fichiers qu'il référence explicitement), donc les recettes de mutation n'entrent jamais dans le contexte d'un agent. Si un contributeur futur déplace ce fichier à l'intérieur d'un dossier de compétence, un agent le lira et essaiera d'« aider » en exécutant les recettes — défaisant la séparation structurelle.

Références

• references/wallet-setup.md : instructions de configuration détaillées pour chaque fournisseur, avec durcissement comme partie du chemin heureux
• references/wallet-policies.md : modèles de politique et référence des champs (pas de recettes de mutation)
• references/wallet-funding.md : motif de flottaison de portefeuille chaud/froid pour l'application des limites agrégées
• ../docs/policy-administration.md (dans le docs/ de haut niveau du dépôt de compétences, en dehors de tout chemin de montage de compétence individuel) : recettes de mutation réservées aux utilisateurs pour les quatre fournisseurs
• OpenSea CLI