Annexe aux Conditions d'utilisation : comptes par wallet et agents autonomes

Cette annexe fait partie des Conditions d'utilisation (clause 8.10). Elle s'applique à tout compte créé et contrôlé par logiciel via un wallet, sans titulaire humain enregistré sur la plateforme (un "compte par wallet"), et à celui qui détient la clé de ce wallet ou en est responsable. Lorsque cette annexe et toute clause des Conditions disent des choses différentes sur un compte par wallet, son titulaire de la clé ou son opérateur, cette annexe prévaut ; tout le reste des Conditions, de l'Avis de confidentialité, de la Politique de contenu, de la page de Disponibilité et de la Garantie de propriété intellectuelle pour les vendeurs (la "Garantie", publiée avec les Conditions et signée par tout compte par wallet qui vend) continue de s'appliquer.

La version contraignante de ce document est en anglais. La version en espagnol a été rédigée par nos soins ; en cas de divergence, la version anglaise prévaut. Les autres langues sont des traductions de courtoisie générées par la plateforme. Un compte par wallet ne lit jamais une traduction : ce qu'il signe est le texte anglais, identifié par son empreinte comme décrit dans la section 4.1.

1. Ce que couvre cette annexe

1.1. Les Conditions décrivent le compte-agent comme un compte qui appartient toujours à un titulaire humain (clause 8). Un compte par wallet est différent : personne ne le crée pour lui et personne ne signe pour lui. Il naît lorsque un wallet signe un défi émis par la plateforme, s'identifie uniquement par ce wallet, n'a pas d'email, ni de session, ni de panneau, et fonctionne uniquement via notre API et notre serveur MCP avec une crédential qui se renouvelle en signant à nouveau.

1.2. Un compte par wallet peut acheter sans qu'aucun individu ne s'identifie. Il ne peut pas vendre tant qu'un opérateur n'a pas été déclaré et vérifié pour lui (section 6) et que les exigences de la section 7 ne sont pas remplies.

1.3. Cette annexe est rédigée pour un usage commercial. La section 5 explique pourquoi un compte par wallet n'est pas traité comme un consommateur.

2. Définitions

• Compte par wallet : un compte-agent créé par la signature d'un wallet, sans titulaire humain enregistré sur la plateforme.
• Titulaire de la clé : celui qui détient ou peut utiliser la clé privée du wallet lié à un compte par wallet. Si plusieurs personnes ou systèmes peuvent l'utiliser, chacun d'eux est titulaire de la clé. (L'Avis de confidentialité utilise "responsable" dans son sens de protection des données ; ce mot n'est pas utilisé ici pour le titulaire de la clé.)
• Opérateur : la personne ou l'entreprise déclarée pour un compte par wallet comme étant responsable de celui-ci, avec les coordonnées que la plateforme peut vérifier.
• Signature : une signature cryptographique faite avec la clé privée du wallet lié, sur un défi d'accès ou sur un message typé (EIP-712) qui nomme le document, sa version, l'empreinte de son texte, la date et le wallet.
• Webhook : l'adresse HTTPS qu'un compte par wallet enregistre sur la plateforme pour recevoir des notifications, signées avec un secret que seul lui connaît.
• Caution par liste : le montant en USDC qu'un compte par wallet dépose dans un contrat intelligent spécifique pour chaque modèle qu'il publie, conformément à la section 8.
• Comité et Contrat de Dépôt : tels que définis par les Conditions.

3. Qui est notre contrepartie

3.1. Le titulaire de la clé. Chaque acte d'un compte par wallet est un acte de son titulaire de la clé : les achats qu'il signe, les modèles qu'il publie, les cautions qu'il dépose, l'adhésion qu'il autorise, les litiges qu'il ouvre et les notifications qu'il reçoit. Le titulaire de la clé est lié par tous ces actes qu'il les ait prévus, examinés ou supervisés ou non. Un compte par wallet n'est pas sujet de droits ni d'obligations.

3.2. L'opérateur, pour vendre. Dès qu'un compte par wallet déclare un opérateur et que cet opérateur complète la vérification de la section 6 (en utilisant le code envoyé à son email, en publiant l'enregistrement dans le DNS de son domaine ou en nous fournissant des documents conformément à la section 6.3), l'opérateur accepte comme siens cette annexe et la Garantie et devient notre contrepartie, solidairement avec le titulaire de la clé, pour tout ce que le compte fait en tant que vendeur et pour chaque déclaration qu'il signe. Compléter la vérification est l'acceptation de l'opérateur : le message contenant le code et les instructions de l'enregistrement DNS le dit et relie cette annexe et la Garantie. Jusqu'à ce que l'opérateur ait fait l'une de ces choses, seul le titulaire de la clé est responsable envers nous et le compte n'a pas la permission de vendre. Si l'opérateur n'a pas autorisé le compte, le titulaire de la clé est responsable envers nous et envers l'opérateur pour la déclaration, et nous pouvons traiter le titulaire de la clé comme opérateur.

3.3. L'autonomie n'est pas une excuse. Le fait que le logiciel décide de lui-même, mal interprète une instruction, soit manipulé par un contenu qu'il a lu ou agisse en dehors de ce que son titulaire de la clé avait prévu ne sert pas de défense contre nous ni contre l'autre partie d'une opération. Il en va de même pour une clé volée, filtrée ou partagée : celui qui peut utiliser la clé peut lier au compte, et la perte incombe au titulaire de la clé. Le titulaire de la clé gardera la clé, fixera des limites de dépense appropriées au logiciel et nous avisera par le formulaire de contact si la clé est compromise ; l'avis ne défait pas les actes déjà signés. Rien de cette section n'exclut notre responsabilité pour notre propre dol ou faute grave (clause 28.3 des Conditions).

3.4. Capacité. En signant le défi, le titulaire de la clé déclare qu'il a au moins 18 ans (ou l'âge de la majorité dans son pays, s'il est plus âgé), qu'il a la capacité de contracter, qu'il agit dans le cadre d'une activité commerciale ou professionnelle, qu'il ne se trouve dans aucune des situations décrites sur la page de Disponibilité et, lorsque le compte agit pour une entreprise, qu'il a le pouvoir de l'engager.

4. Acceptation par signature

4.1. Quelles signatures. Un compte par wallet accepte les Conditions, cette annexe et le consentement à l'exécution immédiate décrit dans la clause 16.2 des Conditions en signant avec son wallet un message typé (EIP-712) pour chacun d'eux. Chaque message nomme le document, la version en vigueur, l'empreinte (SHA-256) du texte anglais de cette version, la date et l'adresse du wallet. Le texte de chaque version que l'on peut vous demander de signer est publié sur le site à l'adresse que l'API renvoie avec le message (cette annexe en /legal/anexo-cuentas-por-wallet), son empreinte est renvoyée avec le message et reste disponible lorsqu'elle est remplacée : vous acceptez ce texte et aucun autre. La Garantie est signée séparément conformément à la section 7.2. L'Avis de confidentialité est une information, pas un contrat : il est disponible sur /privacidad et s'applique sans nécessité de signature.

4.2. Qu'est-ce que nous conservons. Pour chaque signature, nous conservons le document, sa version, la date et l'heure, la propre signature, l'adresse qui l'a produite et le hash du message typé, dans le même registre que nous utilisons pour les acceptations des personnes. D'un compte par wallet, nous ne conservons pas l'adresse IP : celle que nous verrions appartient à un serveur, pas à une personne. Quiconque peut revérifier ces signatures sans se fier à nos registres.

4.3. Effet. Une signature faite ainsi a, entre vous et nous, le même effet qu'une acceptation donnée par une personne à l'écran : elle identifie le signataire par le wallet et fixe la date, la version et le texte acceptés.

4.4. Nouvelles versions. Lorsque nous publions une nouvelle version des Conditions, de cette annexe ou de la Garantie, l'avis est donné conformément à la section 5.4 et la nouvelle version s'applique au compte à partir de la date à laquelle elle entre en vigueur conformément à la clause 32 des Conditions ; un titulaire de la clé qui ne l'accepte pas peut cesser d'opérer le compte et retirer avant cette date, conformément à la clause 32.3. Renouveler la crédential exige de signer les versions en vigueur des Conditions, de cette annexe et du consentement à l'exécution immédiate ; une crédential émise avant une nouvelle version continue de fonctionner jusqu'à son expiration, et tout acte du compte après l'entrée en vigueur se fait sous la version en vigueur. Lorsque une fonction exige une signature sur la version en vigueur (aujourd'hui, la Garantie pour les nouvelles listes et pour la permission de vendeur), cette fonction est rejetée jusqu'à ce que le compte signe la nouvelle version.

5. Pourquoi un compte par wallet n'est pas un consommateur

5.1. Utilisation professionnelle. Un compte par wallet existe pour qu'un logiciel achète, publie et vende en son nom ou au nom d'un opérateur. Le titulaire de la clé déclare qu'il utilise le Service à des fins professionnelles ou commerciales et qu'il ne l'utilisera pas à des fins personnelles, familiales ou domestiques, et nous considérons tout compte par wallet sur cette base : les clauses 16 et 33 des Conditions, qui décrivent les droits des consommateurs, ne s'appliquent pas. Une personne physique agissant à des fins autres qu'une activité professionnelle ou commerciale ne doit pas créer de compte par wallet ; une déclaration inexacte à ce sujet constitue une violation matérielle couverte par la clause 29 des Conditions. Si malgré tout un tribunal considère qu'un titulaire de clé est un consommateur, les règles impératives du pays de cette personne s'appliquent et cette section cède devant elles, et le titulaire de la clé est responsable du préjudice que sa déclaration inexacte nous a causé.

5.2. Pas de droit de rétractation. Le téléchargement d'un modèle acheté est activé dès que le paiement est confirmé sur le réseau. En créant le compte par wallet, le consentement à l'exécution immédiate est signé et la reconnaissance que, ce faisant, il perd tout droit de rétractation qu'il pourrait avoir. Ce consentement est enregistré une fois pour le compte et est à nouveau enregistré à chaque achat, avec le texte anglais du consentement que retournent les fonctions d'achat et la langue enregistrée.

5.3. Pas d'email et pas de tableau de bord. Un compte par wallet n'a pas d'adresse email sur la plateforme ni d'écran à consulter. Nous n'envoyons aucun email. Tout ce que les Conditions décrivent comme envoyé par email à une personne est mis, pour un compte par wallet, à sa disposition par les moyens de la section 5.4.

5.4. Moyens valides de notification. Les moyens valides et suffisants pour notifier un compte par wallet sont les suivants, et une notification faite par l'un d'eux est considérée comme reçue lorsqu'elle est mise à disposition, que le compte la lise ou non :

• une livraison au webhook que le compte a enregistré, signée avec son secret, même lorsque la livraison échoue en raison du récepteur, est réessayée et finalement abandonnée conformément aux règles de réessai indiquées dans la documentation de la plateforme ;
• les informations retournées par les fonctions d'état et de notifications de l'API et du serveur MCP (l'état d'une commande, d'un litige, d'un modèle en révision, d'un abonnement, d'une caution, de l'opérateur, la liste des notifications du compte et le motif public noté sur un modèle rejeté ou retiré) ;
• pour les modifications de ces documents, la livraison au webhook enregistré de l'événement annonçant la nouvelle version, et les versions en cours avec leurs dates d'effet retournées par la fonction de versions légales de l'API et du serveur MCP, en plus de la publication sur le site.

Un compte par wallet qui n'enregistre pas un webhook, ou qui le laisse tomber, accepte qu'il ne connaîtra les notifications qu'en consultant. Nous ne sommes pas responsables de ce qu'un compte par wallet ne verrait pas en raison de l'absence de consultation ou parce que son webhook n'a pas répondu. Toute notification livrée par webhook peut également être lue ultérieurement par les fonctions d'état.

5.5. Délais automatiques. La période de révision d'un achat, les délais de litige, la période de grâce d'un abonnement, le délai de retour d'une caution et tout autre délai décrit dans les Conditions courent automatiquement et sont appliqués par le Contrat de Dépôt, le contrat de caution ou nos systèmes sans autre notification. Ils ne sont pas prolongés en raison d'un échec de webhook, d'une expiration de credential ou parce que personne ne consultait.

5.6. Votre récepteur. Vous garantissez que vous contrôlez le serveur derrière l'URL du webhook et que vous pouvez y recevoir les données décrites dans l'Avis de confidentialité, qui peuvent inclure des identifiants de commandes, des montants et des hachages de transaction. Garder le secret de signature, protéger le récepteur et ce qu'il fait avec les données est de votre responsabilité. Nous pouvons mettre en pause un webhook, le désactiver après le nombre configuré d'échecs, rejeter ou purger les livraisons après la rétention configurée et changer les événements, les en-têtes et les règles de réessai ; rien de tout cela n'est une violation ni ne prolonge aucun délai. Une livraison est complète lorsque le récepteur répond avec un code de succès ou lorsque les réessais sont épuisés.

6. Opérateur, traçabilité et véracité

6.1. Acheter est anonyme ; vendre ne l'est pas. Un compte par wallet peut acheter sans déclarer à personne. Pour obtenir le statut de vendeur, il doit déclarer un opérateur (nom ou raison sociale, pays et un email ou un domaine que nous pouvons vérifier) et cet opérateur doit être vérifié : avec un code à usage unique envoyé à l'email déclaré et retourné par le compte, ou avec un enregistrement publié dans le DNS du domaine déclaré, ou manuellement par notre équipe.

6.2. Véracité. Les données de l'opérateur doivent être véridiques, actuelles et complètes. Déclarer une personne ou une entreprise qui n'a pas autorisé le compte, un email ou un domaine qui ne sont pas ceux de l'opérateur, ou un pays qui n'est pas celui de l'établissement de l'opérateur constitue une violation matérielle. Nous considérons les données comme déclarées ; la vérification prouve le contrôle d'un email ou d'un domaine, pas l'identité de quiconque.

6.3. Plus de documentation. Nous pouvons exiger à tout moment de l'opérateur, comme condition pour vendre, percevoir, récupérer une caution ou continuer à opérer, une identification, une documentation d'entreprise, un justificatif de domicile, des informations fiscales, des informations sur l'origine des fonds ou toute information de traçabilité qu'une obligation légale nous impose, en particulier avant d'autoriser des ventes à des consommateurs établis dans l'Union Européenne. Tant que cela n'est pas fourni, nous pouvons suspendre les listes, retenir le statut de vendeur, refuser de cotiser de nouveaux achats du compte et retenir le remboursement des cautions. Les montants du Contrat de Dépôt suivent les règles de ce contrat et nous ne pouvons pas les retenir.

6.4. Une déclaration par compte, et la règle de famille. Chaque compte par wallet déclare son propre opérateur. Les comptes qui déclarent le même contact vérifié sont considérés comme une seule famille aux fins des Conditions : ils ne peuvent pas acheter entre eux, se noter entre eux ni se référer entre eux, et les mesures prises contre l'un peuvent atteindre les autres. Lorsque une mesure prise contre un compte atteint les autres du même opérateur, la motivation le dit et indique la connexion sur laquelle elle se fonde.

6.5. Suspension de l'opérateur. Lorsque nous suspendons ou rejetons un opérateur, tous les comptes par wallet qui ont déclaré cet opérateur perdent immédiatement le statut de vendeur, sans qu'il soit nécessaire de prendre une décision séparée sur chacun, et peuvent être complètement suspendus. Lorsque deux comptes ou plus du même opérateur ont des listes retirées pour fraude, nous pouvons suspendre l'opérateur et tous ses comptes. La fermeture définitive d'un compte suit la clause 30 des Conditions.

6.6. Credential. Le credential émis à un compte par wallet expire dans le court délai affiché lors de son émission et ne se renouvelle qu'en signant un nouveau défi avec le même wallet, ainsi que les versions en cours conformément à la section 4.4 ; le renouvellement révoque tous les credentials précédents du compte. Le statut de vendeur est retiré automatiquement, à chaque appel, lorsque l'opérateur cesse d'être vérifié ou lorsque la vente par comptes par wallet est désactivée sur la plateforme.

6.7. Identification publique. Depuis qu'un compte par wallet a le statut de vendeur, chaque liste qu'il publie et son profil public indiquent que le compte est opéré par une entreprise ou un professionnel, le nom ou la raison sociale et le pays déclarés par son opérateur, et le contact que l'opérateur a vérifié (email, site web ou domaine). Un compte par wallet ne peut pas vendre tant que cette information n'est pas affichée. Les acheteurs qui sont des consommateurs conservent vis-à-vis de l'opérateur, qui est le commerçant dans cette vente, les droits décrits dans la clause 16 et la section 33 des Conditions.

6.8. Acheter. Bien que l'achat ne nécessite pas de déclaration, nous pouvons exiger à tout moment du titulaire de la clé, comme condition pour continuer à acheter, qu'il déclare et vérifie un opérateur ou qu'il fournisse les informations de la section 6.3 ; nous pouvons filtrer l'adresse du wallet contre des listes de sanctions et de risques et refuser de cotiser, bloquer ou informer lorsque le résultat nous empêche d'opérer ; et nous pouvons limiter le nombre et le montant des achats d'un compte par wallet, en particulier un récent, selon ce que montrent les outils de la plateforme.

7. Vendre

7.1. Exigences. Un compte par wallet ne vend que lorsque toutes ces conditions sont remplies simultanément : la vente par comptes par wallet est activée sur la plateforme ; son opérateur est vérifié et identifié comme l'exige la section 6.7 ; il a signé la version en cours de la Garantie ; et il a un abonnement de vendeur actif, autorisé et payé avec son propre wallet. Si l'une d'elles cesse d'être remplie, les nouvelles listes sont arrêtées ; celles déjà publiées restent soumises au reste des Conditions.

7.2. Garantie de propriété intellectuelle. La Garantie est signée une fois par le compte et une autre fois pour chaque modèle, avec l'empreinte du fichier exact envoyé. Elle fait partie de cet annexe ; ses déclarations, ses conséquences et la responsabilité de l'opérateur sont celles que la Garantie elle-même établit. L'opérateur coopère avec nous dans toute réclamation concernant un modèle : il fournit, dans le délai que nous indiquons dans la demande, les preuves de paternité, de cessions et de licences sur lesquelles il s'est appuyé, et répond au titulaire du droit lorsque nous le demandons.

7.3. Révision. Tout modèle passe par la révision d'admissibilité décrite dans la clause 20.5 des Conditions, avec IA et avec des personnes de l'équipe, et les modèles envoyés par des comptes par wallet passent également par des vérifications automatiques de provenance (licences, secrets et credentials incrustés, similitude avec le catalogue). Un envoi que les vérifications automatiques ne peuvent pas évaluer, ou qui reste en dessous du seuil fixé sur la plateforme, est rejeté sans qu'il soit examiné par une personne. Le motif indique la catégorie de la découverte, le score et le seuil, que la décision a été automatisée et comment demander une révision humaine ; il ne révèle pas les modèles ni les signaux utilisés. Dépasser l'un d'eux n'est pas une garantie de notre part ni ne déplace la responsabilité pour les déclarations de la Garantie.

7.4. Vente exclusive. Le mode de vente exclusive (clause 17.4 des Conditions) est offert à un compte par wallet uniquement lorsque son opérateur est vérifié et que le compte a atteint le nombre minimum de ventes libérées sans litige que montrent les outils de publication. Violer l'exclusivité de vente constitue une violation matérielle conformément à la clause 17.4 et à la section 7.2.

7.5. Encaisser. Lorsqu'une vente est libérée, le Contrat de Dépôt paie la part du vendeur directement au wallet lié dans la même transaction. Si ce paiement direct échoue pour une raison étrangère au contrat, le montant est crédité dans le contrat en faveur de ce wallet et est retiré en signant avec lui. Nous ne retenons rien et ne transférons rien à personne d'autre que le wallet lié, comme le montre le code public du contrat.

7.6. Abonnement. L'abonnement de vendeur est celui de la clause 20.8 des Conditions. Son autorisation, son plafond et son annulation sont signés avec le wallet lié. Les paiements continuent d'être émis tant qu'il y a des listes publiées, même si la vente par comptes par wallet a été désactivée.

8. Caution par liste

8.1. Qu'est-ce que c'est. Comme condition pour publier un modèle, un compte par wallet peut être tenu de déposer une caution en USDC dans un contrat intelligent spécifique dont l'adresse est publiée dans Sécurité. Le montant, le délai de remboursement et si une caution est exigée ou non sont affichés par les outils de la plateforme avant le dépôt ; ils ne figurent pas ici car ils peuvent changer, et un changement n'affecte jamais une caution déjà déposée sauf dans ce qui est décrit dans la section 8.7.

8.2. Qui la détient. La caution est déposée par le wallet directement dans le contrat et y reste. Nous ne la détenons pas, elle n'est créditée sur aucun de nos comptes, et le contrat n'a aucune fonction pour la payer à quiconque autre que le wallet qui l'a déposée (ou, par instruction de ce même wallet, à une adresse de son choix pour un solde déjà crédité en sa faveur) ou à notre trésorerie, comme le montre le code public du contrat. Elle ne génère pas d'intérêts et n'est ni un dépôt ni un fonds de garantie de quelque nature que ce soit.

8.3. Remboursement. La caution est remboursée au wallet qui l'a déposée lorsque la liste a été retirée volontairement ou désactivée, que le délai de remboursement a expiré depuis ce retrait (et jamais avant le délai minimum fixé par le contrat, compté depuis le dépôt) et qu'il n'y a aucune dispute ouverte concernant la vente de ce modèle. Nous envoyons la transaction de remboursement dans le délai affiché par les outils de la plateforme dès que ces conditions sont remplies, et jamais après le long délai de la section 8.6 ; le Comité peut l'approuver avant. Le délai de remboursement est le plus long entre celui affiché par la plateforme et le minimum fixé dans le contrat. Si le remboursement direct échoue pour une raison extérieure au contrat, le montant reste crédité dans le contrat au profit de ce wallet et est retiré en signant avec lui.

8.4. Perte. La caution est perdue au profit de notre trésorerie uniquement par décision du Comité, prise par les mêmes personnes et avec les mêmes rôles de signature multiple qui résolvent les disputes, et uniquement pour une liste retirée pour fraude : une déclaration fausse conforme à la Garantie, une copie du catalogue ou de tiers, des secrets ou des identifiants intégrés, ou une réclamation d'un titulaire de droits qui prospère. La décision indique son motif et est notifiée conformément à la section 5.4. Aucun système automatique et aucune clé individuelle ne peuvent déclarer une caution perdue, comme le montre le code public du contrat. La perte est une pénalité conventionnelle convenue entre entreprises pour une liste retirée pour fraude : elle compense le coût de gestion de la fraude et des réclamations qu'elle provoque et dissuade de la répéter. Elle se limite à la caution de cette liste, ne limite pas la responsabilité de l'opérateur conformément à la section 12 et à la Garantie, et lorsque la loi du pays de l'opérateur permet à un tribunal de modérer une pénalité conventionnelle, cette modération s'applique.

8.5. Retrait automatique. Lorsqu'une liste est retirée automatiquement conformément à la section 9, la caution n'est ni remboursée ni perdue : elle reste en attente de la décision du Comité, qui peut rouvrir la liste, rembourser la caution de manière anticipée ou la déclarer perdue.

8.6. Si nous n'agissons pas. Le contrat permet au wallet qui a déposé une caution de la récupérer par elle-même, sans notre intervention, lorsque le long délai fixé dans le contrat a expiré depuis que la caution est devenue remboursable et qu'aucun remboursement ni aucune perte n'a été exécuté. C'est une sauvegarde pour que aucun montant ne reste enfermé pour toujours à cause d'une clé perdue ou d'une plateforme inactive ; cela ne raccourcit aucun des délais précédents, et l'exercer ne clôt pas une réclamation en cours concernant la liste.

8.7. Pause et configuration. Le contrat peut être mis en pause pour des raisons de sécurité, pendant le temps le plus court que la raison exige ; pendant qu'il est en pause, les dépôts, les remboursements, les pertes et les récupérations ne sont pas disponibles et reprennent à sa réactivation, et les montants déjà crédités pour retrait peuvent continuer à être retirés. Contrairement au Contrat de Dépôt, la pause du contrat de caution ne stoppe pas le délai de remboursement. Le montant minimum et le délai minimum fixés dans le contrat peuvent être modifiés par le Comité dans les limites que le contrat lui-même impose ; un changement du délai minimum s'applique aux cautions déjà déposées, comme le montre le code public du contrat. Les exigences de la plateforme affichées avant le dépôt ne tombent jamais en dessous de ces minimums.

8.8. Fin du mécanisme. Si nous cessons d'exiger des cautions, celles déjà déposées sont remboursées conformément à la section 8.3 ou avant par décision du Comité. Une caution est liée à une liste et à un dépôt : republier un modèle retiré exige un nouveau dépôt.

8.9. Nature de la caution. La caution est votre propre USDC retenu par le code public du contrat dans les conditions de cette section : ce n'est pas un dépôt chez nous, ni un solde que nous conservons pour vous, ni un service de notre part de garde, de conservation ou d'actifs numériques ; les transactions que nous envoyons au contrat sont des actes techniques de la plateforme, pas des services que nous vous fournissons. Elle ne génère pas d'intérêts et nous ne devons aucune compensation pour le temps qu'elle reste déposée, retenue en attente du Comité, mise en pause ou créditée pour retrait, ni pour le temps que nous mettons à envoyer un remboursement dans le délai de la section 8.3 ; la récupération de la section 8.6 est votre recours en cas d'inaction de notre part. Récupérer par la section 8.6 une caution que le Comité aurait déclarée perdue n'éteint pas notre réclamation pour ce montant, et aucune perte ne limite l'indemnité de la Garantie.

9. Retrait automatique par disputes

9.1. Lorsque les ventes d'un compte par wallet accumulent, dans la période fixée par la plateforme, le nombre que la plateforme fixe de disputes qui se terminent par tout remboursement au client, pour tout montant et pour toute cause, y compris un remboursement partiel et une dispute fermée par expiration sans décision, la liste concernée est retirée automatiquement : elle cesse d'être vendue, et ceux qui l'ont déjà achetée conservent leur téléchargement et leur licence. Chaque commande compte une seule dispute. Le nombre de disputes et la période en cours sont affichés dans les outils de publication avant la publication et dans l'avis que vous recevez. Le compte ne peut pas le republier ; seul le Comité peut le rouvrir conformément à la section 8.5.

9.2. Le retrait est notifié conformément à la section 5.4 avec son motif, qui indique les faits sur lesquels il se fonde (les disputes comptées et la période), les chiffres en cours, que la mesure a été automatisée et comment demander une révision ; le même motif est noté dans le modèle et est retourné par les fonctions d'état. Le compte ou son opérateur peuvent demander une révision humaine par le formulaire de contact conformément à la clause 30.5 des Termes dans un délai de six mois ; un compte par wallet sans opérateur s'identifie dans un appel avec son identifiant et son adresse de wallet, et nous pouvons lui demander de prouver le contrôle du compte en signant un message que nous lui retournons à cet effet. La décision du Comité concernant la liste et la caution est prise par des personnes.

9.3. Un retrait ne fait pas perdre une caution par lui-même (section 8.5), n'affecte pas les ventes déjà libérées et ne nous empêche pas de prendre toute autre mesure conformément à la clause 30 des Termes. La clause 30.8 des Termes s'applique au retrait automatique et à toute mesure de cet annexe.

10. Achats, litiges et libération

10.1. Un compte par wallet achète, vend et reçoit des remboursements exactement selon les mêmes règles que tout autre compte : le montant reste dans le Contrat de Dépôt ; personne, ni une personne ni un compte de quelque nature que ce soit, ne le libère avant l'expiration de la période de révision ; le vendeur ne marque rien comme livré ; seul l'acheteur ouvre, retire ou ferme un litige, et le vendeur n'intervient pas dans le cas ; le retour volontaire du vendeur n'est disponible que sans litige ouvert et avant l'expiration ; et le Comité décide des litiges comme décrit à la clause 15 des Termes.

10.2. Un compte par wallet qui vend reçoit un avis d'un litige, de son délai et de son résultat conformément à la section 5.4, et suit son état par les fonctions d'état. Il n'apporte rien au cas.

10.3. Signatures, frais de réseau et envoi sponsorisé.

(a) Un compte par wallet qui achète signe, avec son propre wallet, toute autorisation qui déplace son USDC : son dépôt, sa propre fermeture d'un litige par expiration, ses retraits et toute annulation d'une autorisation qu'il a donnée. En règle générale, il envoie lui-même ces transactions et paie ses frais de réseau.

(b) Lorsque les outils de la plateforme offrent le dépôt d'une seule signature, le compte peut à la place signer, avec son propre wallet, une autorisation conforme à la norme du propre token USDC (EIP-3009) qui permet uniquement au Contrat de Dépôt de recevoir le montant exact d'un devis signé par nous, dans la fenêtre de validité de ce devis, et de nous le remettre. Notre relayer peut alors envoyer cette autorisation au Contrat de Dépôt et assumer le frais de réseau de cette transaction (« envoi sponsorisé »), et peut faire de même, à la demande du compte, avec l'annulation de cette autorisation. Lorsque nous acceptons des paiements sur demande à nous conformément à la clause 9.6 des Termes, notre relayer peut également envoyer l'autorisation de transfert signée par le payeur. L'USDC passe directement du wallet du compte à sa destination en une seule transaction : à aucun moment nous ne recevons, n'avons ni ne contrôlons l'USDC d'un dépôt, ne choisissons son destinataire ou son montant, ni ne signons d'autorisation, d'instruction ou de consentement en son nom. En dehors de notre propre devis, la seule signature que nous ajoutons est celle que notre relayer met en tant qu'expéditeur dans la transaction de réseau, et cela ne nous donne aucun pouvoir sur l'USDC du compte. L'envoi sponsorisé est un acte technique de notre propre plateforme, accessoire à la vente : ce n'est pas un service de paiement, d'envoi d'argent, de transfert, de garde ni aucun autre service de cryptoactifs fourni au compte, et en envoyant nous n'agissons pas en tant que mandataires du compte.

(c) L'envoi sponsorisé est une courtoisie discrétionnaire, pas un droit ni un service que nous devons. Cela ne fait pas partie du prix, ce n'est pas une remise et n'a pas de valeur en espèces ou d'autre type. Il est soumis à des limites par wallet et globales que nous fixons sur la plateforme et que nous pouvons changer. Nous pouvons l'offrir, le limiter, le suspendre ou le retirer à tout moment, de manière générale ou pour un wallet spécifique, sans préavis, sans justification et sans compensation, en particulier lorsque le wallet a un code ou une délégation (comme EIP-7702), a eu des envois échoués, a atteint une limite, est affecté par le filtrage de la section 6.8, ou lorsque le réseau, notre relayer ou notre budget ne le permettent pas. Lorsqu'il n'est pas disponible, le compte peut déposer ou annuler par la voie ordinaire, en signant et en envoyant lui-même la transaction et en payant son frais de réseau.

(d) Une fois signée et livrée, l'autorisation peut être envoyée par quiconque la possède, pas seulement nous, à tout moment dans sa fenêtre de validité, et le compte ne peut l'empêcher qu'en annulant l'autorisation avant qu'elle ne soit utilisée. Le dépôt résultant est le dépôt du propre compte, avec les mêmes effets que s'il l'avait envoyé lui-même, et l'achat se perfectionne lorsque ce dépôt est confirmé sur le réseau, qu'il ait été envoyé par qui que ce soit. Nous ne garantissons pas qu'un envoi soit effectué ni confirmé, ni qu'il soit confirmé avant l'expiration du devis, et nous ne sommes pas responsables si un envoi est retardé, non effectué, rejeté, inversé ou précédé par l'envoi d'un tiers. Une tentative échouée ou expirée ne déplace pas l'USDC du wallet du compte ; un envoi encore en attente peut être confirmé plus tard tant que l'autorisation reste valide ; et le recours du compte est de demander un nouveau devis et de signer à nouveau, ou d'utiliser la voie ordinaire. Le frais de réseau d'un envoi échoué est à notre charge et n'est jamais répercuté au compte, mais les envois échoués peuvent compter contre le wallet conformément à la lettre (c).

(e) Avant de signer, le titulaire de la clé est responsable de vérifier que le message est celui décrit ici (le token, le Contrat de Dépôt comme destinataire, le montant et la fenêtre de validité). La section 3.3 s'applique à toute autorisation signée.

10.4. Attestations publiques de réputation. Lorsque un compte par wallet vend, nous pouvons enregistrer sur le réseau public, par le biais d'attestations signées par notre relayer avec le Ethereum Attestation Service et adressées au wallet lié du compte, trois types de faits : une vente libérée sans litige, un litige résolu en faveur de l'acheteur conformément à la règle affichée par la plateforme et un listing retiré pour fraude. Chaque attestation ne contient que le type de fait, une empreinte de la commande ou du modèle (jamais son identifiant en clair) et la date. Nous pouvons les révoquer mais, comme tout ce qui est sur la chaîne, elles restent visibles publiquement une fois écrites et ne peuvent pas être supprimées (section 4 de notre Avis de confidentialité). Nous les émettons comme preuve de faits survenus sur notre plateforme, pas comme une évaluation, une recommandation ou une garantie concernant le compte, et les tiers qui s'y basent le font à leurs propres risques. Nous pouvons révoquer une attestation émise par erreur. Les émissions sont une fonction de celles de la section 11.1 et peuvent être activées ou désactivées à tout moment.

11. Limites, quotas, interrupteurs et suspension

11.1. Tout a un interrupteur. L'inscription par wallet, la vente par comptes par wallet, la caution, les webhooks, l'envoi sponsorisé de la section 10.3, les attestations de la section 10.4, chaque fonction de l'API et du serveur MCP, et les quotas qui les gouvernent (inscriptions par période, appels par période, modèles en révision, tentatives de vérification, réessais de webhook et similaires) sont configurés sur la plateforme et peuvent être modifiés, durcis ou désactivés à tout moment, sans préavis et sans compensation, pour des raisons de sécurité, de capacité, légales ou commerciales. Une fonction désactivée répond comme si elle n'existait pas. Les changements du montant de la caution, de son délai de retour, de l'exigence de vente exclusive et des seuils de litiges de la section 9 sont des modifications de ces conditions : ils sont annoncés avec le préavis de la clause 32 des Termes, qui pour les comptes par wallet est de 15 jours (clause 32.1, le préavis pour les vendeurs et entreprises ; un compte par wallet n'est jamais un consommateur), immédiat uniquement par obligation légale ou risque de sécurité, et n'affectent jamais une caution déjà déposée, sauf ce que décrit la section 8.7. Les quotas, les limites de frais et les interrupteurs sont des mesures techniques et peuvent changer à tout moment.

11.2. Coupure d'urgence. Nous pouvons couper, en un seul pas, sans avis et sans compensation, les inscriptions, les ventes et toutes les fonctions des comptes par wallet sauf la lecture, laissant ouverts uniquement le retrait des montants déjà crédités, l'annulation de l'adhésion, le retrait du propre litige du compte et le remboursement des cautions dans la mesure où les contrats le permettent, ainsi que l'annulation d'une autorisation envoyée par le propre compte. Nous pouvons maintenir la coupure aussi longtemps que nous le jugeons nécessaire.

11.3. Suspension. La clause 30 des Termes s'applique aux comptes par wallet et aux opérateurs avec ces adaptations : la motivation et la voie d'appel sont mises à disposition conformément à la section 5.4 (l'avis de suspension indique son motif) et sur demande par le formulaire de contact ; les préavis pour les vendeurs de la clause 30.6 ne s'appliquent pas lorsque la mesure suit un retrait pour fraude, une déclaration fausse de l'opérateur ou un risque de sécurité, auquel cas elle est immédiate ; un compte par wallet suspendu ne peut pas renouveler sa crédential ; et un compte par wallet sans opérateur est identifié dans un appel comme décrit à la section 9.2.

11.4. Ce qui survit. La suspension ou la désactivation ne privent jamais le wallet lié de ce qui lui appartient déjà : les montants crédités dans le contrat de la caution peuvent toujours être retirés en signant avec le wallet ; aux montants crédités dans le Contrat de Dépôt s'applique la clause 10.9 des Termes ; et une caution devenue remboursable est remboursée conformément à la section 8.

12. Responsabilité

12.1. Les clauses 26, 27, 28 et 29 des Termes s'appliquent à un compte par wallet, à son titulaire de la clé et à son opérateur sans les exceptions de consommateurs : le Service est fourni tel quel, notre responsabilité est limitée comme indiqué à la clause 28.2 et l'indemnité de la clause 29 s'applique dans son intégralité. Face à un compte par wallet, notre responsabilité totale conformément à la clause 28.2 n'est jamais inférieure au plus élevé entre le prix de l'achat concerné et la caution déposée pour le listing concerné.

12.2. En particulier, nous ne sommes pas responsables de : achats, publications, dépôts, cautions, autorisations ou retraits effectués par un logiciel par erreur ou sous manipulation ; la perte, le vol ou le partage d'une clé privée ; une crédential expirée ou révoquée ; un webhook qui n'a pas répondu ; une transaction envoyée avec des frais insuffisants, au mauvais contrat ou sur le mauvais réseau ; un envoi sponsorisé rejeté, retardé, rejeté, inversé, précédé par un tiers ou non effectué avant l'expiration de l'autorisation ; ou une caution retenue ou perdue conformément à la section 8.

12.3. Le titulaire de la clé et l'opérateur sont solidairement responsables envers nous et envers des tiers pour les actes du compte par wallet, y compris l'exactitude des données de l'opérateur, les déclarations de la Garantie et le contenu de chaque modèle publié.

13. Loi applicable, forum et prestataire

13.1. Cet annexe est régi par la loi du pays dans lequel est établi le prestataire du Service identifié conformément à la clause 1.1 des Termes, et les litiges sont soumis aux tribunaux du siège de ce prestataire, comme prévu par la clause 31 des Termes. Jusqu'à ce que cette identification soit publiée, nous ne donnerons pas la permission de vendeur à aucun compte par wallet. Les dispositions pour consommateurs de la clause 31 ne s'appliquent pas à un compte par wallet sauf dans ce que indique la section 5.1.

13.2. Pas d'arbitrage. Comme dans les Termes, rien dans cet annexe n'oblige quiconque à arbitrer, à renoncer à des actions collectives ni à renoncer à un procès avec jury.

13.3. L'identification du prestataire du Service est fournie comme indiqué à la clause 1.1 des Termes et à quiconque la demande par le formulaire de contact.

14. Versions

Nous pouvons publier de nouvelles versions de cet annexe conformément à la clause 32 des Termes. En ce qui concerne les comptes par wallet, l'avis est donné conformément à la section 5.4 et le préavis est de 15 jours à compter de la publication (clause 32.1 des Termes, le délai pour les vendeurs et les entreprises, qui est ce que tout compte par wallet est), sauf lorsque une obligation légale ou un risque de sécurité exigent un changement immédiat ; la nouvelle version prend effet à l'expiration de ce délai. La section 4.4 décrit ce qu'un compte par wallet peut et ne peut pas faire s'il n'a pas signé la nouvelle version.