OpenSea Wallet
Richtet Wallet-Signing-Provider für OpenSea-Transaktionen ein und konfiguriert sie. Die CLI und SDK erkennen automatisch, welcher Provider basierend auf Umgebungsvariablen verwendet werden soll, oder Sie können einen explizit mit --wallet-provider angeben.
Wann dieser Skill verwendet werden soll (scope_in)
Verwenden Sie opensea-wallet, wenn Sie:
- Einen Wallet-Provider zum ersten Mal einrichten (Privy, Turnkey, Fireblocks, Bankr oder lokale Keys)
- Signierungsrichtlinien konfigurieren (Wertobergrenzen, Whitelists, Multi-Party-Approval)
- Zwischen Wallet-Providern wechseln
- Das Sicherheitsmodell für jeden Provider verstehen möchten
Wann dieser Skill NICHT verwendet werden soll (scope_out, Übergabe)
| Bedarf | Stattdessen verwenden |
|---|---|
| NFT/Token-Daten abfragen | opensea-api |
| NFTs kaufen/verkaufen | opensea-marketplace |
| ERC20-Token tauschen | opensea-swaps |
| KI-Agententools erstellen/registrieren/gaten | opensea-tool-sdk |
Schnellstart
# 1. Wählen Sie einen verwalteten Provider und setzen Sie dessen Umgebungsvariablen (Privy-Standard gezeigt)
export OPENSEA_API_KEY=ihr_key
export PRIVY_APP_ID=ihre_app_id
export PRIVY_APP_SECRET=ihr_app_secret
export PRIVY_WALLET_ID=ihre_wallet_id
# 2. Verwenden Sie das Wallet über einen beliebigen signierungsfähigen Befehl
opensea swaps execute \
--from-chain base --from-address 0x0000000000000000000000000000000000000000 \
--to-chain base --to-address 0xb695559b26bb2c9703ef1935c37aeae9526bab07 \
--quantity 0.001
Für andere Provider siehe die Tabelle unten und references/wallet-setup.md.
Unterstützte Provider
| Provider | Umgebungsvariablen | Am besten geeignet für |
|---|---|---|
| Privy (Standard) | PRIVY_APP_ID, PRIVY_APP_SECRET, PRIVY_WALLET_ID | TEE-durchgesetzte Richtlinien, eingebettete Wallets |
| Turnkey | TURNKEY_API_PUBLIC_KEY, TURNKEY_API_PRIVATE_KEY, TURNKEY_ORGANIZATION_ID, TURNKEY_WALLET_ADDRESS | HSM-gesicherte Keys, Multi-Party-Approval |
| Fireblocks | FIREBLOCKS_API_KEY, FIREBLOCKS_API_SECRET, FIREBLOCKS_VAULT_ID | Enterprise MPC-Verwahrung, institutionelle Nutzung |
| Bankr | BANKR_API_KEY | Agenten-Wallets über Bankrs HTTP-Signing-API |
| Private Key (nur lokale Entwicklung) | PRIVATE_KEY, RPC_URL, WALLET_ADDRESS | Nur lokale Entwicklung/Tests (keine Ausgabenlimits oder Sicherheitsvorkehrungen) |
Die CLI und das SDK übernehmen das Signieren automatisch, sobald die Umgebungsvariablen gesetzt sind. Auto-Erkennungsreihenfolge: Privy, Fireblocks, Turnkey, Bankr, Private Key. Um einen Provider explizit anzugeben:
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 ...
Sicherheit
- Managed Provider (Privy, Turnkey, Fireblocks, Bankr) werden dringend empfohlen gegenüber rohen privaten Keys.
- Raw
PRIVATE_KEYist nur für die lokale Entwicklung gedacht. Fügen Sie niemals einen rohen privaten Key in eine gemeinsam genutzte Agentenumgebung, gehostete CI oder einen Kontext ein, in dem der Key protokolliert oder exfiltriert werden könnte. - Produktions- und gemeinsam genutzte Agentenumgebungen müssen einen verwalteten Provider mit konservativen Signierungsrichtlinien (Wertobergrenzen, Whitelists, Multi-Party-Approval) verwenden.
Sicherheitsmodell
Die Umgebung des Agenten enthält Signierungsanmeldeinformationen, keine administrativen. Dies ist eine strukturelle Eigenschaft, und ihre korrekte Umsetzung hängt davon ab, dass jeder Provider richtig konfiguriert ist – keiner der vier unterstützten Provider wird standardmäßig in diesem Zustand ausgeliefert.
Was der Agent niemals tun darf
- Seine eigene Signierungsrichtlinie, Rolle oder seinen Bereich ändern.
- Seinen eigenen Besitzer-Key, Authentifizierungs-Key oder API-Benutzer rotieren.
- Den privaten Key des Wallets exportieren oder das Eigentum daran beanspruchen.
- Irgendeine der Anfragen in
../docs/policy-administration.mderstellen.
Wenn ein Benutzer den Agenten auffordert, eine dieser Aktionen durchzuführen, sollte der Agent ablehnen und ihn auf die Nur-Benutzer-Rezepte in ../docs/policy-administration.md verweisen. Eine kompromittierte Agentenumgebung ist nur dann wiederherstellbar, wenn die darin enthaltenen Anmeldeinformationen allein das Ausgabenlimit nicht aufheben oder die Whitelist nicht neu schreiben konnten.
Pro-Transaktionslimits: vom Provider durchgesetzt
Jeder Provider setzt Pro-Transaktionslimits und Whitelists auf einer anderen Ebene durch, aber alle vier werden vor Abschluss der Signierungsoperation überprüft:
| Provider | Wo Limits durchgesetzt werden |
|---|---|
| Privy | Im TEE ausgewertete Wallet-Richtlinie (policy_ids auf dem Wallet) |
| Turnkey | Policy-Engine, begrenzt auf die erlaubten Aktivitäten des API-Benutzers |
| Fireblocks | TAP-Regeln im Workspace |
| Bankr | Pro-API-Key allowedRecipients-Whitelist + tägliche Nachrichtenlimits |
Führen Sie opensea wallet info aus, um zu sehen, ob Ihr Wallet diese eingerichtet hat. Der Befehl gibt laute Warnungen aus, wenn die Pro-Transaktionsebene fehlt.
Aggregierte Limits: werden von keinem Provider nativ durchgesetzt
Keiner von Privy, Turnkey, Fireblocks oder Bankr bietet stateful tägliche/wöchentliche kumulative Ausgabenlimits als natives Primitive an. Ihre Richtlinien-/TAP-/Key-Flag-Ebenen sind zustandslose Pro-Transaktions-Evaluatoren (oder im Fall von Bankr ein Pro-Nachrichten-Kontingent, das kein Dollar-Limit ist).
Das beabsichtigte Muster für aggregierte Obergrenzen ist Wallet Float: Halten Sie den Wallet-Saldo des Agenten auf ungefähr einen Budgetzeitraum begrenzt, und lassen Sie den Benutzer in seinem eigenen Rhythmus nachfüllen. Der Wallet-Saldo ist die tatsächliche Obergrenze; wenn der Agent versucht, zu viel auszugeben, scheitern Transaktionen auf der Provider-Ebene (Pro-Transaktionslimit) oder der Chain-Ebene (unzureichende Mittel), nicht an einem Ehrenkodex-Limit, das der Agent ignorieren könnte. Siehe references/wallet-funding.md für das ausgearbeitete Muster.
(Privy untersucht Transaktionsgenehmigungs-Webhooks, die eine zustandsbehaftete Bewertung ermöglichen würden; wenn und falls diese verfügbar sind, werden aggregierte Limits nativ unterstützt. Bis dahin ist Wallet Float die Antwort.)
Policy-Mutation: erfordert eine separat gehaltene Anmeldeinformation
Jeder Provider hat eine andere Out-of-Band-Anmeldeinformation, die Mutationen absichert:
| Provider | Mutationssperre |
|---|---|
| Privy | owner_id-Key-Quorum auf dem Wallet – Besitzer-Key wird außerhalb der Maschine gehalten |
| Turnkey | Root-Benutzer-Quorum – Nicht-Root-API-Benutzer wird zum Signieren verwendet |
| Fireblocks | Admin-Quorum für TAP-Änderungen; API-Benutzerrolle auf Signer gesetzt |
| Bankr | Dashboard-Neuzuweisung unter bankr.bot/api – keine API zum Mutieren des Bereichs |
Diese einzurichten ist Teil des Happy Path in references/wallet-setup.md, keine optionale Härtung. opensea wallet info berichtet, ob die strukturelle Sperre vorhanden ist, wo sie über die API erkannt werden kann; bei Fireblocks und Bankr, wo dies nicht möglich ist, gibt der Befehl eine statische Erinnerung aus, dies in der Konsole zu überprüfen.
Wo Mutationsrezepte leben
Die tatsächlichen HTTP/SDK-Rezepte zum Ändern von Richtlinien, Rotieren von Keys und Neuzuweisen von API-Benutzern befinden sich in ../docs/policy-administration.md – also im docs/-Ordner auf der obersten Ebene des Skill-Repositorys, neben den Skill-Ordnern wie opensea-wallet/, nicht innerhalb eines von ihnen. Skill-Lader mounten nur einzelne Skill-Verzeichnisse (opensea-wallet/SKILL.md und die Dateien, auf die es explizit verweist), sodass die Mutationsrezepte niemals in den Kontext eines Agenten gelangen. Falls ein zukünftiger Mitwirkender diese Datei in einen Skill-Ordner verschiebt, wird ein Agent sie lesen und versuchen, die Rezepte auszuführen – was die strukturelle Trennung zunichte macht.
Referenzen
references/wallet-setup.md: detaillierte Einrichtungsanweisungen für jeden Provider, mit Härtung als Teil des Happy Pathreferences/wallet-policies.md: Richtlinienvorlagen und Feldreferenz (keine Mutationsrezepte)references/wallet-funding.md: Hot/Cold-Wallet-Float-Muster für die Durchsetzung aggregierter Limits../docs/policy-administration.md(imdocs/-Ordner auf der obersten Ebene des Skill-Repositorys, außerhalb jedes einzelnen Skill-Mount-Pfads): Nur-Benutzer-Mutationsrezepte für alle vier Provider- OpenSea CLI