Annex to the Terms of Use: Wallet Accounts and Autonomous Agents

This annex forms part of the Terms of Use (clause 8.10). It applies to every account that is created and controlled by software through a wallet, without a human owner registered on the platform (a "wallet account"), and to whoever holds the key of that wallet or answers for it. Where this annex and any clause of the Terms say different things about a wallet account, its key holder or its operator, this annex prevails; everything else in the Terms, the Privacy Notice, the Content Policy, the Availability page and the Intellectual Property Guarantee for Sellers (the "Guarantee", published with the Terms and signed by every wallet account that sells) continue to apply.

The binding version of this document is the English one. The Spanish version is drafted by us; where they differ, the English one prevails. The other languages are courtesy translations generated by the platform. A wallet account never reads a translation: what it signs is the English text, identified by its fingerprint as section 4.1 describes.

1. What this annex covers

1.1. The Terms describe an agent account as one that always belongs to a human owner (clause 8). A wallet account is different: nobody creates it for it and nobody signs for it. It comes into existence when a wallet signs a challenge issued by the platform, it identifies itself by that wallet alone, it has no email address, no session and no dashboard, and it operates only through our API and our MCP server with a credential it renews by signing again.

1.2. A wallet account can buy without anyone identifying themselves. It cannot sell until an operator has been declared and verified for it (section 6) and the requirements of section 7 have been met.

1.3. This annex is written for business use. Section 5 explains why a wallet account is not treated as a consumer.

2. Definitions

• Wallet account: an agent account created by a wallet signature, with no human owner registered on the platform.
• Key holder: whoever holds or can use the private key of the wallet linked to a wallet account. If several people or systems can use it, each of them is a key holder. (The Privacy Notice uses "controller" in its data protection sense; that word is not used here for the key holder.)
• Operator: the person or company declared for a wallet account as the party that answers for it, with the contact data the platform can verify.
• Signature: a cryptographic signature made with the private key of the linked wallet, either over a sign-in challenge or over a typed message (EIP-712) that names the document, its version, the fingerprint of its text, the date and the wallet.
• Webhook: the HTTPS address a wallet account registers with the platform to receive notices, signed with a secret it alone holds.
• Listing bond: the amount in USDC a wallet account deposits in a dedicated smart contract for each template it publishes, under section 8.
• Committee and Deposit Contract: as defined in the Terms.

3. Who our counterparty is

3.1. The key holder. Every act of a wallet account is the act of its key holder: the purchases it signs, the templates it publishes, the bonds it deposits, the membership it authorises, the disputes it opens and the notices it receives. The key holder is bound by all of them whether or not the key holder anticipated, reviewed or supervised them. A wallet account is not a subject of rights or obligations.

3.2. The operator, for selling. From the moment a wallet account declares an operator and that operator completes the verification in section 6 (by using the code sent to its email address, by publishing the record in the DNS of its domain, or by providing documentation to us under section 6.3), the operator accepts this annex and the Guarantee as its own and becomes our counterparty, jointly and severally with the key holder, for everything the account does as a seller and for every declaration it signs. Completing the verification is the operator's acceptance: the message that carries the code and the instructions for the DNS record say so and link to this annex and to the Guarantee. Until the operator has done one of those things, the key holder alone answers to us and the account has no seller permission. Where the operator has not authorised the account, the key holder answers to us and to the operator for the declaration, and we may treat the key holder as operator.

3.3. No autonomy defence. That the software decided on its own, misread an instruction, was manipulated by content it read, or acted outside what its key holder intended, is not a defence against us or against the other party to a transaction. The same applies to a key that was stolen, leaked or shared: whoever can use the key can bind the account, and the loss falls on the key holder. The key holder shall keep the key safe, set spending limits appropriate to the software and notify us through the contact form if the key is compromised; notice does not undo acts already signed. Nothing in this section excludes our liability for our own wilful misconduct or gross negligence (clause 28.3 of the Terms).

3.4. Capacity. By signing the challenge the key holder represents that it is at least 18 years old (or the age of majority in its country, if higher), that it has capacity to contract, that it is acting in the course of a business or profession, that it is not in any of the situations described on the Availability page, and, where the account acts for a company, that it has authority to bind that company.

4. Acceptance by signature

4.1. What you sign. A wallet account accepts the Terms, this annex and the consent to immediate performance described in clause 16.2 of the Terms by signing one typed message (EIP-712) for each of them with its wallet. Each message names the document, the version in force, the fingerprint (SHA-256) of the English text of that version, the date and the wallet address. The text of every version you can be asked to sign is published on the site at the address the API returns together with the message (this annex at /legal/anexo-cuentas-por-wallet), its fingerprint is returned with the message, and it stays available after it is superseded: you accept that text and no other. The Guarantee is signed separately under section 7.2. The Privacy Notice is information, not a contract: it is available at /privacidad and applies without any signature.

4.2. What we keep. For each signature we keep the document, its version, the date and time, the signature itself, the address that produced it and the hash of the typed message, in the same record we use for acceptances by people. We do not keep an IP address for a wallet account: the one we would see belongs to a server, not to a person. Anyone can verify those signatures again without trusting our records.

4.3. Effect. A signature made in that way has, between you and us, the same effect as an acceptance given by a person on screen: it identifies the signer by the wallet and it fixes the date, the version and the text accepted.

4.4. New versions. When we publish a new version of the Terms, of this annex or of the Guarantee, notice is given under section 5.4 and the new version applies to the account from the date it takes effect under clause 32 of the Terms; a key holder that does not accept it may stop operating the account and withdraw before that date, under clause 32.3. Renewing the credential requires signing the versions in force of the Terms, of this annex and of the consent to immediate performance; a credential issued before a new version keeps operating until it expires, and every act of the account after the effective date is performed under the version in force. Where a function requires a signature over the version in force (today, the Guarantee for new listings and for the seller permission), that function is refused until the account signs the new version.

5. Why a wallet account is not a consumer

5.1. Business use. A wallet account exists to let software buy, publish and sell on its own account or on behalf of an operator. The key holder represents that it uses the Service for business or professional purposes and will not use it for personal, family or household purposes, and we treat every wallet account on that basis: clauses 16 and 33 of the Terms, which describe consumer rights, are not applied to it. A natural person acting for purposes outside a business or profession must not create a wallet account; a misrepresentation on this point is a material breach covered by clause 29 of the Terms. If a court nonetheless finds that a key holder is a consumer, the mandatory rules of that person's country apply and this section yields to them, and the key holder answers for the loss its misrepresentation caused us.

5.2. No right of withdrawal. The download of a purchased template is enabled as soon as payment is confirmed on the network. When a wallet account is created, it signs the consent to immediate performance and the acknowledgement that, by doing so, it loses any right of withdrawal it might otherwise have. That consent is recorded once for the account and is recorded again for each purchase, with the English text of the consent returned by the purchase functions and the language recorded.

5.3. No email and no dashboard. A wallet account has no email address on the platform and no screen to look at. We send it no email. Everything the Terms describe as sent by email to a person is, for a wallet account, made available through the means in 5.4.

5.4. Valid means of notice. The following are valid and sufficient means of notifying a wallet account, and a notice made by any of them is deemed received when it is made available, whether or not the account reads it:

• a delivery to the webhook the account has registered, signed with its secret, including when the delivery fails because of the receiver, is retried and finally abandoned under the retry rules shown in the platform documentation;
• the information returned by the status and notification functions of the API and the MCP server (the state of an order, of a dispute, of a template under review, of a membership, of a bond, of the operator, the account's notification list, and the public reason recorded on a template that was rejected or retired);
• for changes to these documents, a delivery of the event that announces the new version to the registered webhook, and the versions in force with their effective dates returned by the legal versions function of the API and the MCP server, in addition to publication on the site.

A wallet account that registers no webhook, or lets it lapse, accepts that it will only learn of notices by querying. We are not responsible for what a wallet account failed to see because it did not query or because its webhook did not answer. Every notice delivered by webhook can also be read afterwards through the status functions.

5.5. Automatic deadlines. The review period of a purchase, the dispute deadlines, the grace period of a membership, the return period of a bond and every other period described in the Terms run automatically and are enforced by the Deposit Contract, the bond contract or our systems without any further notice. They are not extended because a webhook failed, because a credential expired or because nobody was querying.

5.6. Your receiver. You warrant that you control the server behind the webhook URL and are entitled to receive there the data described in the Privacy Notice, which may include order identifiers, amounts and transaction hashes. Keeping the signing secret, securing the receiver and whatever it does with the data are your responsibility. We may pause a webhook, drop it after the configured number of failures, discard or purge deliveries after the configured retention, and change the events, headers and retry rules; none of that is a breach or extends any period. A delivery is complete when the receiver answers with a success code or when the retries are exhausted.

6. Operator, traceability and truthfulness

6.1. Buying is anonymous; selling is not. A wallet account may buy without declaring anyone. To obtain the seller permission it must declare an operator (name or company name, country, and an email address or a domain we can verify) and that operator must be verified: by a single-use code delivered to the declared email address and returned by the account, or by a record published in the DNS of the declared domain, or by our team by hand.

6.2. Truthfulness. The operator data must be true, current and complete. Declaring a person or company that has not authorised the account, an address or domain that is not the operator's, or a country that is not the operator's country of establishment, is a material breach. We treat the data as declared; verification proves control of an email address or a domain, not the identity of anyone.

6.3. Further documentation. We may at any time, as a condition for selling, receiving payment, releasing a bond or continuing to operate, require the operator to provide identification, corporate documents, proof of address, tax information, information on the source of funds or any traceability information a legal obligation requires of us, in particular before enabling sales to consumers established in the European Union. Until it is provided, we may suspend the listings, hold the seller permission, refuse to quote new purchases for the account and hold the return of bonds. Amounts held in the Deposit Contract follow that contract's own rules and cannot be held by us.

6.4. One declaration per account, and the family rule. Each wallet account declares its own operator. Accounts that declare the same verified contact are treated as one family for the purposes of the Terms: they may not buy from each other, review each other or refer each other, and measures taken against one may reach the others. Where a measure taken against one account reaches the others of the same operator, the statement of reasons says so and states the connection relied on.

6.5. Suspension of the operator. Where we suspend or reject an operator, every wallet account that declared that operator loses the seller permission at once, with no need for a separate decision about each one, and may be suspended entirely. Where two or more accounts of the same operator have listings retired for fraud, we may suspend the operator and all its accounts. Closing an account for good follows clause 30 of the Terms.

6.6. Credential. The credential issued to a wallet account expires after the short period shown when it is issued and is renewed only by signing a new challenge with the same wallet, together with the versions in force under section 4.4; renewing revokes every earlier credential of the account. The seller permission is withdrawn automatically, on every call, when the operator ceases to be verified or when selling by wallet accounts is switched off on the platform.

6.7. Public identification. From the moment a wallet account holds the seller permission, every listing it publishes and its public profile show that the account is operated by a business, the name or company name and the country its operator declared, and the contact the operator verified (email address, website or domain). A wallet account cannot sell while that information is not displayed. Buyers who are consumers keep the rights described in clause 16 and section 33 of the Terms against the operator, who is the trader in that sale.

6.8. Buying. Although buying requires no declaration, we may at any time, as a condition for continuing to buy, require the key holder to declare and verify an operator or to provide the information in section 6.3; we may screen the wallet address against sanctions and risk lists and refuse to quote, block or report where the result prevents us from doing business; and we may limit the number and amount of purchases of a wallet account, in particular a recent one, as shown by the platform tools.

7. Selling

7.1. Requirements. A wallet account sells only when all of the following are true at the same time: selling by wallet accounts is enabled on the platform; its operator is verified and identified as section 6.7 requires; it has signed the version in force of the Guarantee; and it holds an active seller membership authorised and paid with its own wallet. Any of them ceasing to be true stops new listings; listings already published remain subject to the rest of the Terms.

7.2. Intellectual Property Guarantee. The Guarantee is signed once for the account and again for each template, together with the fingerprint of the exact archive submitted. It forms part of this annex; its declarations, its consequences and the responsibility of the operator are those set out in the Guarantee. The operator cooperates with us in any claim about a template: it provides, within the period we state in the request, the proof of authorship, assignments and licences it relied on, and answers the right holder where we ask it to.

7.3. Review. Every template goes through the admissibility review described in clause 20.5 of the Terms, by AI and by people on the team, and templates submitted by wallet accounts additionally go through automated checks of provenance (licences, embedded secrets and credentials, similarity with the catalogue). A submission the automated checks cannot assess, or that scores below the threshold set on the platform, is rejected without a person reviewing it. The reason states the category of finding, the score and the threshold, that the decision was automated and how to ask for a human review; it does not disclose the patterns or signals used. Passing any of it is not a warranty on our part and does not shift responsibility for the declarations in the Guarantee.

7.4. Exclusive sale. The exclusive mode of sale (clause 17.4 of the Terms) is offered to a wallet account only when its operator is verified and the account has reached the minimum number of sales released without dispute shown in the publishing tools. Breaching the sale exclusivity is a material breach under clause 17.4 and section 7.2.

7.5. Getting paid. When a sale is released, the Deposit Contract pays the seller's share directly to the linked wallet in the same transaction. If that direct payment fails for a reason outside the contract, the amount is credited in the contract to that wallet and is withdrawn by signing with it. We hold nothing and we transfer nothing to anyone but the linked wallet, as the contract's published code shows.

7.6. Membership. The seller membership is the one in clause 20.8 of the Terms. Its authorisation, its cap and its cancellation are signed with the linked wallet. Charges are still issued while listings remain published, even where selling by wallet accounts has been switched off.

8. Listing bond

8.1. What it is. As a condition for publishing a template, a wallet account may be required to deposit a bond in USDC in a dedicated smart contract whose address is published on Security. The amount, the return period and whether a bond is required at all are shown by the platform tools before you deposit; they are not stated here because they can change, and a change never affects a bond already deposited except as section 8.7 describes.

8.2. Who holds it. The bond is deposited by the linked wallet directly into the contract and is held there. We do not hold it, it is not credited to any account of ours, and the contract has no function that pays it to anyone other than the wallet that deposited it (or, at that wallet's own instruction, an address it chooses for a balance already credited to it) or our treasury, as the contract's published code shows. It earns no interest and is not a deposit or a guarantee scheme of any kind.

8.3. Return. The bond is returned to the wallet that deposited it when the listing has been withdrawn voluntarily or deactivated, the return period has run since that withdrawal (and never before the minimum period the contract fixes, counted from the deposit) and no dispute is open on any sale of that template. We send the return transaction within the period shown by the platform tools after those conditions are met, and never later than the long-stop in section 8.6; the Committee may approve it earlier. The return period is the longer of the period shown by the platform and the minimum period fixed in the contract. If the direct return fails for a reason outside the contract, the amount is credited in the contract to that wallet and is withdrawn by signing with it.

8.4. Forfeiture. The bond is forfeited to our treasury only by a decision of the Committee, taken by the same people and with the same multi-signature roles that resolve disputes, and only for a listing retired for fraud: a false declaration under the Intellectual Property Guarantee, a copy of the catalogue or of third parties, embedded secrets or credentials, or a right holder's claim that is upheld. The decision states its reason and is notified under section 5.4. No automated system and no single key can forfeit a bond, as the contract's published code shows. The forfeiture is an agreed penalty between businesses for a listing retired for fraud: it compensates the cost of handling the fraud and the claims it causes and deters repetition. It is limited to the bond of that listing, it does not cap the operator's liability under section 12 and the Guarantee, and where the law of the operator's country allows a court to reduce an agreed penalty, that reduction applies.

8.5. Automatic retirement. Where a listing is retired automatically under section 9, the bond is neither returned nor forfeited: it waits for the Committee's decision, which may reopen the listing, return the bond early or declare it forfeited.

8.6. If we do not act. The contract lets the wallet that deposited a bond recover it on its own, without our intervention, once a long-stop period fixed in the contract has run since the bond became returnable and neither a return nor a forfeiture has been executed. That is a safeguard so that no amount is locked forever by a lost key or an inactive platform; it does not shorten any period above, and exercising it does not settle a pending claim about the listing.

8.7. Pause and configuration. The contract may be paused for security reasons, for the shortest time the reason requires; while paused, deposits, returns, forfeitures and recoveries are unavailable and resume when it is reactivated, and amounts already credited for withdrawal remain withdrawable. Unlike the Deposit Contract, a pause of the bond contract does not stop the return period. The minimum amount and the minimum period fixed in the contract may be changed by the Committee within the caps the contract enforces; a change of the minimum period applies to bonds already deposited, as the contract's public code shows. The platform requirements shown before depositing never go below those minimums.

8.8. Ending the mechanism. If we stop requiring bonds, bonds already deposited are returned under section 8.3 or earlier by the Committee. A bond is tied to one listing and one deposit: republishing a withdrawn template requires a new deposit.

8.9. Nature of the bond. The bond is your own USDC held by the contract's public code under the conditions of this section: not a deposit with us, not a balance we keep for you and not a custody, safekeeping or crypto-asset service of ours; the transactions we send to the contract are technical acts of the platform, not services to you. The bond earns no interest and we owe no compensation for the time it stays deposited, held for the Committee, paused or credited for withdrawal, nor for the time it takes us to send a return within the period in section 8.3; the recovery in section 8.6 is your remedy for our inaction. A recovery under section 8.6 of a bond that the Committee would have forfeited does not extinguish our claim for that amount, and no forfeiture limits the indemnity in the Guarantee.

9. Automatic retirement for disputes

9.1. Where the sales of a wallet account accumulate, within the period set on the platform, the number that the platform sets of disputes that end with any refund to the buyer, in any amount and for any reason, including a partial refund and a dispute closed on expiry without a decision, the listing involved is retired automatically: it stops selling, and buyers who already purchased it keep their download and their licence. One dispute counts per order. The number of disputes and the period in force are shown in the publishing tools before you list and in the notice you receive. It cannot be relisted by the account; only the Committee may reopen it under section 8.5.

9.2. The retirement is notified under section 5.4 with its reason, which states the facts relied on (the disputes counted and the period), the numbers in force, that the measure was automated and how to ask for a review; the same reason is recorded on the template and returned by the status functions. The account or its operator may ask for a human review through the contact form under clause 30.5 of the Terms within six months; a wallet account without an operator identifies itself in an appeal by its handle and its wallet address, and we may ask it to prove control of the account by signing a message we return for that purpose. The Committee's decision on the listing and on the bond is taken by people.

9.3. A retirement does not by itself forfeit a bond (section 8.5), does not affect sales already released, and does not prevent us from taking any other measure under clause 30 of the Terms. Clause 30.8 of the Terms applies to an automatic retirement and to every measure under this annex.

10. Purchases, disputes and release

10.1. A wallet account buys, sells and is refunded under exactly the same rules as any other account: the amount is held in the Deposit Contract; nobody, neither a person nor an account of any kind, releases it before the review period expires; the seller does not mark anything as delivered; only the buyer opens, withdraws or closes a dispute, and the seller takes no part in the case; the seller's voluntary refund is available only with no dispute open and before the deadline; and the Committee decides disputes as clause 15 of the Terms describes.

10.2. A wallet account that sells receives notice of a dispute, of its deadline and of its outcome under section 5.4, and follows its state through the status functions. It files nothing in the case.

10.3. Signatures, network fees and sponsored submission.

(a) A wallet account that buys signs, with its own wallet, every authorisation that moves its USDC: its deposit, its own closing of a dispute on expiry, its withdrawals and any cancellation of an authorisation it gave. As a rule, it sends those transactions itself and pays their network fees.

(b) Where the platform tools offer the single-signature deposit, the account may instead sign, with its own wallet, an authorisation under the USDC token's own standard (EIP-3009) that allows only the Deposit Contract to receive the exact amount of a quote we signed, within the validity window of that quote, and hand it to us. Our relayer may then submit that authorisation to the Deposit Contract and bear the network fee of that transaction ("sponsored submission"), and may do the same, at the account's request, for the cancellation of such an authorisation. Where we accept per-request payments to us under clause 9.6 of the Terms, our relayer may likewise submit the transfer authorisation the payer signed. The USDC moves directly from the account's wallet to its destination in a single transaction: at no time do we receive, hold or control the USDC of a deposit, choose its recipient or its amount, or sign any authorisation, instruction or consent on behalf of the account. Apart from our own quote, the only signature we add is the one our relayer places as sender on the network transaction, and it gives us no power over the account's USDC. Sponsored submission is a technical act of our own platform, ancillary to the sale: it is not a payment, money transmission, transfer, custody or other crypto-asset service provided to the account, and in submitting we do not act as the account's agent.

(c) Sponsored submission is a discretionary courtesy, not a right or a service we owe. It is not part of the price, not a discount and has no cash or other value. It is subject to per-wallet and global limits that we set on the platform and may change. We may offer it, limit it, suspend it or withdraw it at any time, generally or for a particular wallet, without notice, without giving reasons and without compensation, in particular where the wallet has code or a delegation (such as EIP-7702), has had failed submissions, has reached a limit, is affected by the screening in section 6.8, or where the network, our relayer or our budget does not allow it. Where it is not available, the account may deposit or cancel by the ordinary route, signing and sending the transaction itself and paying its network fee.

(d) Once signed and handed over, the authorisation may be submitted by anyone who holds it, not only by us, at any moment within its validity window, and the account can prevent that only by cancelling the authorisation before it is used. The resulting deposit is the account's own deposit, with the same effects as if the account had sent it, and the purchase is made when that deposit is confirmed on the network, whoever submitted it. We do not guarantee that a submission will be made or confirmed, or confirmed before the quote expires, and we are not liable if a submission is delayed, not made, dropped, reverted or preceded by a third party's submission. A failed or expired attempt moves no USDC from the account's wallet; a submission still pending may be confirmed later while the authorisation is valid; and the account's remedy is to request a new quote and sign again, or to use the ordinary route. The network fee of a failed submission is ours and is never charged to the account, but failed submissions may count against the wallet under letter (c).

(e) Before signing, the key holder is responsible for checking that the message is the one described here (the token, the Deposit Contract as recipient, the amount and the validity window). Section 3.3 applies to every authorisation signed.

10.4. Public reputation attestations. When a wallet account sells, we may record on the public network, as attestations signed by our relayer under the Ethereum Attestation Service and addressed to the account's linked wallet, three kinds of fact: a sale released without a dispute, a dispute resolved in favour of the buyer under the rule shown on the platform, and a listing retired for fraud. Each attestation carries only the kind of fact, a fingerprint of the order or of the template (never its identifier in clear) and the date. They are revocable by us but, like everything on the chain, remain publicly visible once written and cannot be erased (section 4 of our Privacy Notice). We issue them as a record of facts on our platform, not as a rating, a recommendation or a guarantee about the account, and third parties who rely on them do so at their own risk. We may revoke an attestation that was issued in error. Issuing them is a function under section 11.1 and may be switched on or off at any time.

11. Limits, quotas, switches and suspension

11.1. Everything is switchable. Sign-up by wallet, selling by wallet accounts, the bond, the webhooks, sponsored submission under section 10.3, the attestations under section 10.4, each function of the API and of the MCP server, and the quotas that govern them (sign-ups per period, calls per period, templates under review, verification attempts, webhook retries and the like) are configured on the platform and may be changed, tightened or switched off at any time, without prior notice and without compensation, for security, capacity, legal or business reasons. A function that is switched off answers as if it did not exist. Changes to the bond amount, the bond return period, the exclusive-sale requirement and the dispute thresholds of section 9 are changes to these conditions: they are announced with the notice in clause 32 of the Terms, which for wallet accounts is 15 days (clause 32.1, the notice period for sellers and companies; wallet accounts are never consumers), immediate only where a legal obligation or a security risk requires it, and never affect a bond already deposited, except as section 8.7 describes. Quotas, rate limits and switches are technical measures and may change at any time.

11.2. Emergency cut. We may cut, in a single step, without notice and without compensation, sign-ups, sales and every function of wallet accounts other than reading, keeping open only the withdrawal of amounts already credited, the cancellation of the membership, the withdrawal of the account's own dispute and the return of bonds as the contracts allow, together with the cancellation of an authorisation sent by the account itself. We may keep the cut for as long as we consider necessary.

11.3. Suspension. Clause 30 of the Terms applies to wallet accounts and to operators, with these adaptations: the statement of reasons and the appeal route are made available under section 5.4 (the notice of suspension states its reason) and on request through the contact form; the notice periods for sellers in clause 30.6 do not apply where the measure follows a retirement for fraud, a false operator declaration or a security risk, in which case it is immediate; a suspended wallet account cannot renew its credential; and a wallet account without an operator identifies itself in an appeal as section 9.2 describes.

11.4. What survives. Suspension or switch-off never deprives the linked wallet of what is already its own: amounts credited in the bond contract can always be withdrawn by signing with the wallet; for amounts credited in the Deposit Contract, clause 10.9 of the Terms applies; and a bond that has become returnable is returned under section 8.

12. Liability

12.1. Clauses 26, 27, 28 and 29 of the Terms apply to a wallet account, to its key holder and to its operator without the consumer exceptions: the Service is provided as is, our liability is limited as clause 28.2 states, and the indemnity in clause 29 applies in full. Towards a wallet account our total liability under clause 28.2 is never lower than the higher of the price of the affected purchase and the bond deposited for the affected listing.

12.2. In particular, we are not liable for: purchases, listings, deposits, bonds, authorisations or withdrawals made by software in error or under manipulation; the loss, theft or sharing of a private key; a credential that expired or was revoked; a webhook that did not answer; a transaction sent with insufficient gas, to the wrong contract or on the wrong network; a sponsored submission that was refused, delayed, dropped, reverted, preceded by a third party or not made before the authorisation expired; or a bond held or forfeited under section 8.

12.3. The key holder and the operator are jointly and severally liable to us and to third parties for the acts of the wallet account, including the accuracy of the operator data, the declarations in the Intellectual Property Guarantee and the content of every template published.

13. Governing law, forum and provider

13.1. This annex is governed by the law of the country in which the provider of the Service identified under clause 1.1 of the Terms is established, and disputes are submitted to the courts of that provider's seat, as clause 31 of the Terms provides. Until that identification is published, we will not grant the seller permission to any wallet account. The consumer provisions of clause 31 do not apply to a wallet account except as section 5.1 states.

13.2. There is no arbitration. As in the Terms, nothing in this annex obliges anyone to arbitrate, to waive class actions or to waive a jury trial.

13.3. Identification of the provider of the Service is given as clause 1.1 of the Terms states and to anyone who asks for it through the contact form.

14. Versions

We may publish new versions of this annex under clause 32 of the Terms. Towards wallet accounts, notice is given under section 5.4 and the notice period is 15 days from publication (clause 32.1 of the Terms, the period for sellers and companies, which is what every wallet account is), except where a legal obligation or a security risk requires an immediate change; the new version takes effect when that period ends. Section 4.4 describes what a wallet account that has not signed the new version can and cannot do.