Bitcoin contract templates

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

BITCOIN SALE AGREEMENT

Between:
  SELLER: [FULL LEGAL NAME], [ADDRESS], [ID TYPE AND NUMBER]
  BUYER:  [FULL LEGAL NAME], [ADDRESS], [ID TYPE AND NUMBER]

Date: [DATE]

1. SUBJECT
   The Seller agrees to transfer to the Buyer [AMOUNT] BTC
   ("the Bitcoin"), and the Buyer agrees to pay the Price,
   on the terms below.

2. PRICE AND PRICE SOURCE
   2.1 The Price is [AMOUNT] [CURRENCY].
   2.2 The Price was determined by reference to the rate published
       by [PRICE SOURCE] at [TIME] on [DATE] ([TIMEZONE]),
       being [RATE] [CURRENCY] per BTC, [plus/minus] a premium of
       [X]%.
   2.3 The Price is fixed and does not vary with subsequent
       movements in the market rate.

3. PAYMENT
   3.1 The Buyer shall pay the Price by [METHOD] to
       [ACCOUNT DETAILS OR SEPARATE SCHEDULE].
   3.2 Payment shall be made by [DEADLINE].
   3.3 Payment is deemed made when funds are irrevocably credited
       and cannot be reversed, charged back or recalled.

4. DELIVERY
   4.1 The Seller shall transfer the Bitcoin to the address
       notified by the Buyer in writing ("the Receiving Address").
   4.2 The Buyer shall confirm the Receiving Address by
       [SECOND CHANNEL], and the Seller shall not act on an
       address received by a single channel.
   4.3 The Seller shall first send a test transaction of
       [TEST AMOUNT] BTC. The Buyer shall confirm receipt in
       writing before the balance is sent.
   4.4 Delivery is complete when the transaction has
       [NUMBER] confirmations on the Bitcoin network.
   4.5 Transaction fees are borne by [PARTY].

5. ORDER OF PERFORMANCE
   [CHOOSE ONE]
   (a) Payment first: the Seller shall transfer within
       [PERIOD] of payment being deemed made under clause 3.3.
   (b) Delivery first: the Buyer shall pay within [PERIOD] of
       delivery being complete under clause 4.4.
   (c) Simultaneous, using the escrow arrangement in Schedule 1.

6. SELLER'S WARRANTIES
   The Seller warrants that:
   (a) the Seller is the sole owner of the Bitcoin and has full
       authority to transfer it;
   (b) the Bitcoin is free of any lien, pledge or third-party claim;
   (c) the Bitcoin was lawfully acquired and does not derive from
       any unlawful activity;
   (d) the Seller is not subject to any sanctions measure.

7. BUYER'S WARRANTIES
   The Buyer warrants that:
   (a) the funds used to pay the Price were lawfully acquired;
   (b) the Buyer is acting on their own behalf and not for an
       undisclosed third party;
   (c) the Receiving Address is controlled by the Buyer;
   (d) the Buyer is not subject to any sanctions measure.

8. IRREVERSIBILITY AND ADDRESS RISK
   8.1 The parties acknowledge that Bitcoin transactions cannot
       be reversed.
   8.2 The Seller is not liable for loss resulting from an
       incorrect Receiving Address notified by the Buyer.

9. TAXES
   Each party is solely responsible for determining and
   discharging their own tax obligations arising from this
   transaction, and for their own reporting.

10. RECORDS
    Each party shall retain a copy of this Agreement, the
    transaction ID, and evidence of payment, for not less than
    [PERIOD].

11. GOVERNING LAW AND DISPUTES
    This Agreement is governed by the law of [JURISDICTION].
    [Insert dispute resolution clause: see Template 16.]

12. ENTIRE AGREEMENT
    This document contains the entire agreement between the
    parties and supersedes all prior discussions.

SIGNED:

Seller: ______________________  Date: __________
Buyer:  ______________________  Date: __________

[Witnesses or notarisation if required in your jurisdiction]

Notes. Clause 5 is the whole negotiation: whoever performs second holds the risk. For anything material, use escrow rather than trusting the order of performance. Clause 3.3 matters more than it looks, since several common payment methods can be reversed for weeks after they appear to have settled.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

ESCROW AGREEMENT

Between:
  SELLER: [NAME AND DETAILS]
  BUYER:  [NAME AND DETAILS]
  ESCROW AGENT: [NAME, CAPACITY, DETAILS]

Date: [DATE]

1. PURPOSE
   The parties have entered into a sale agreement dated [DATE]
   ("the Sale Agreement"). This Agreement appoints the Escrow
   Agent to hold [the Bitcoin / the funds / both] until the
   release conditions are satisfied.

2. WHAT IS HELD
   2.1 [The Seller shall transfer [AMOUNT] BTC to the escrow
       address [ADDRESS or MULTISIG DESCRIPTION].]
   2.2 [The Buyer shall transfer [AMOUNT] [CURRENCY] to the
       escrow account identified separately.]

3. ESCROW MECHANISM
   [CHOOSE ONE]
   (a) The Escrow Agent holds sole control of the escrow address.
   (b) The escrow address is a 2-of-3 multisignature address with
       one key held by each of the Seller, the Buyer and the
       Escrow Agent. The Escrow Agent's key is used only to break
       a deadlock under clause 6.

4. RELEASE CONDITIONS
   The Escrow Agent shall release to the Buyer when all of the
   following are satisfied:
   (a) the Escrow Agent has confirmed receipt of the Price in
       cleared and irreversible funds;
   (b) [ANY FURTHER CONDITION];
   (c) [PERIOD] has elapsed without a dispute notice under
       clause 6.

5. RETURN CONDITIONS
   The Escrow Agent shall return the Bitcoin to the Seller if:
   (a) the Price is not received by [DEADLINE]; or
   (b) both parties jointly instruct return in writing.

6. DISPUTES
   6.1 Either party may give written notice of dispute to the
       Escrow Agent before release.
   6.2 On receiving a dispute notice, the Escrow Agent shall
       release nothing until it receives either joint written
       instructions or a decision under clause 7.
   6.3 [Optional: the Escrow Agent may decide the dispute acting
       reasonably on the documents submitted, and the parties
       agree to be bound by that decision.]

7. DEADLOCK
   If no joint instruction or decision is received within
   [PERIOD], the matter shall be determined under
   [DISPUTE RESOLUTION MECHANISM: see Template 16].

8. ESCROW AGENT'S DUTIES AND LIMITS
   8.1 The Escrow Agent acts as a neutral stakeholder and owes
       no duty of advice to either party.
   8.2 The Escrow Agent shall follow this Agreement strictly and
       exercise no discretion beyond it.
   8.3 The Escrow Agent is not liable except for [gross
       negligence / wilful misconduct].
   8.4 The Escrow Agent's fee is [AMOUNT], payable by [PARTY],
       and is earned on [EVENT].
   8.5 The Escrow Agent shall keep the escrow key material secure
       and shall not disclose it to either party.

9. RECORDS
   The Escrow Agent shall provide each party with the transaction
   IDs of all movements into and out of the escrow address.

10. GOVERNING LAW
    [JURISDICTION].

SIGNED by all three parties:

Seller: __________  Buyer: __________  Escrow Agent: __________

Before anything else: holding another person's funds pending a condition may itself be a regulated activity where you are, depending on how the funds are held and whether it is done in the course of a business. That question is about the escrow agent's own position, not the parties', and it is not answered by anything in this document. Establish it before agreeing to act, and before asking anyone else to.

Notes. Option 3(b), a 2-of-3 multisig, is materially safer than 3(a): the escrow agent alone cannot move funds, and if they disappear, buyer and seller can still cooperate to resolve. Use it wherever the counterparties are technically capable.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

SECURED LOAN AGREEMENT

Between:
  LENDER:   [NAME AND DETAILS]
  BORROWER: [NAME AND DETAILS]

Date: [DATE]

1. LOAN
   1.1 The Lender lends [AMOUNT] [CURRENCY] ("the Principal").
   1.2 The Principal shall be advanced by [METHOD] on [DATE].

2. INTEREST
   2.1 Interest accrues at [RATE]% per annum, calculated
       [daily/monthly] on the outstanding Principal.
   2.2 Interest is payable [monthly in arrears / on repayment].

3. TERM AND REPAYMENT
   3.1 The Loan is repayable in full on [DATE] ("the Maturity
       Date").
   3.2 The Borrower may repay early [without penalty / subject to
       [X] days' notice].

4. COLLATERAL
   4.1 The Borrower shall transfer [AMOUNT] BTC ("the Collateral")
       to [a 2-of-3 multisignature address with keys held by the
       Borrower, the Lender and [THIRD PARTY] / the address
       specified in Schedule 1].
   4.2 The Collateral secures all sums owing under this Agreement.
   4.3 Beneficial ownership of the Collateral remains with the
       Borrower until enforcement under clause 7.
   4.4 The Lender shall not lend, rehypothecate, stake or
       otherwise use the Collateral, and shall hold it
       unencumbered and segregated.

5. VALUATION
   5.1 The Collateral is valued by reference to [PRICE SOURCE],
       measured at [TIME] [TIMEZONE] each [day/week].
   5.2 The Loan-to-Value ratio ("LTV") is the outstanding balance
       divided by the value of the Collateral.
   5.3 The LTV at the date of this Agreement is [X]%.

6. MARGIN
   6.1 If the LTV exceeds [MARGIN CALL LTV]%, the Lender may give
       written notice requiring the Borrower to either transfer
       additional Collateral or repay part of the Principal, so
       as to restore the LTV to [TARGET LTV]% or below.
   6.2 The Borrower shall comply within [PERIOD] of the notice.
   6.3 Notice shall be given by [METHOD] to [CONTACT], and shall
       be deemed received [WHEN].

7. EVENTS OF DEFAULT AND ENFORCEMENT
   7.1 Each of the following is an Event of Default:
       (a) failure to repay on the Maturity Date;
       (b) failure to comply with a margin call under clause 6.2;
       (c) the LTV exceeding [LIQUIDATION LTV]%;
       (d) [OTHER].
   7.2 On an Event of Default, the Lender may, after giving
       [PERIOD] written notice, sell so much of the Collateral as
       is necessary to discharge the outstanding balance and
       reasonable costs.
   7.3 The Lender shall sell in a commercially reasonable manner
       and shall account to the Borrower in writing for the sale
       price, costs deducted, and any surplus.
   7.4 Any surplus shall be returned to the Borrower within
       [PERIOD]. Any shortfall remains payable by the Borrower.

8. RETURN OF COLLATERAL
   On repayment in full, the Lender shall cooperate to release
   the Collateral to the Borrower within [PERIOD].

9. TAX
   Each party is responsible for its own tax position. The
   parties acknowledge that the transfer of Collateral, its
   return, and any enforcement sale may each have tax
   consequences, and that each party has taken its own advice.

10. WARRANTIES
    The Borrower warrants sole ownership of the Collateral, that
    it is free of other security, and that it was lawfully
    acquired.

11. GOVERNING LAW AND DISPUTES
    [JURISDICTION]. [See Template 16.]

SIGNED:

Lender: ______________  Borrower: ______________

Before anything else: lending as a regular activity, or lending to consumers rather than between businesses, commonly requires authorisation and brings consumer credit rules with it: prescribed pre-contract disclosure, cooling-off periods, limits on default interest and restrictions on enforcement. Those requirements attach to the lender. Establish whether they apply before lending, and note that a loan made without a required authorisation can be unenforceable against the borrower.

Notes. Clause 4.4 governs where the collateral is held and who can move it: it governs where the collateral is held and who can move it. Clause 6.3 matters more than borrowers expect: if notice is deemed received when sent to an email you do not check, a liquidation can happen before you know a margin call was made. And take advice on clause 9 before signing: in some systems transferring collateral is itself a taxable disposal.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

GIFT OF BITCOIN: DECLARATION SKELETON

I, [DONOR FULL LEGAL NAME], of [ADDRESS], born [DATE OF BIRTH],
declare as follows.

1. GIFT
   I have transferred to [RECIPIENT FULL LEGAL NAME], of
   [ADDRESS], [AMOUNT] BTC ("the Gift").

2. TRANSFER DETAILS
   2.1 Date of transfer: [DATE]
   2.2 Transaction ID: [TXID]
   2.3 Receiving address: [ADDRESS]
   2.4 Value at the date of transfer: [AMOUNT] [CURRENCY],
       by reference to [PRICE SOURCE] at [TIME] [TIMEZONE].

3. NATURE OF THE TRANSFER
   3.1 The Gift is made freely and voluntarily, out of natural
       love and affection, and with no expectation of repayment,
       return, service or benefit of any kind.
   3.2 The Gift is not a loan. No sum is or will become repayable.
   3.3 The Gift is not payment for goods, services or any other
       consideration.
   3.4 The Gift is [outright and unconditional / subject to the
       conditions in clause 4].

4. CONDITIONS [DELETE IF NONE]
   [Set out any condition. Note that conditional gifts are treated
   very differently between jurisdictions and may not be
   effective. Take advice before using this clause.]

5. CAPACITY AND SOLVENCY
   5.1 I make this Gift of my own free will, without pressure
       from any person.
   5.2 I am solvent, and the Gift does not render me unable to
       meet my liabilities as they fall due.

6. SOURCE
   The Bitcoin given was lawfully acquired by me [in/from
   [BRIEF DESCRIPTION]] and does not derive from any unlawful
   activity.

7. TAX
   The parties acknowledge that this Gift may have tax
   consequences for either or both of them, that reporting
   obligations may arise, and that each has taken or declined
   independent advice.

8. RECORDS
   Each party shall retain an original of this document.

9. GOVERNING LAW
   This declaration is governed by the law of [JURISDICTION].

SIGNED by the Donor:

Donor: ______________________  Date: __________

Acknowledged and accepted by the Recipient:

Recipient: __________________  Date: __________

Witness: ____________________  Date: __________
Name and address of witness: [DETAILS]

Notes. Clause 5.2 exists because gifts made while insolvent can be clawed back by creditors in most systems. Clause 3.2 is the one that protects the recipient years later when a bank or tax authority asks where the money came from. Many jurisdictions require gifts above a threshold to be reported, and several require a specific form or a notary, so check locally before relying on this alone.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

KEY HOLDER APPOINTMENT

Between:
  PRINCIPAL:  [NAME, ADDRESS, DATE OF BIRTH]
  KEY HOLDER: [NAME, ADDRESS, DATE OF BIRTH]

Date: [DATE]

1. APPOINTMENT
   The Principal appoints the Key Holder to hold the item
   described in clause 2, on the terms of this Agreement.

2. WHAT IS HELD
   2.1 The Key Holder holds: [DESCRIBE WITHOUT DISCLOSING
       CONTENTS, e.g. "one sealed envelope marked A", "one
       hardware signing device", "one metal backup plate in a
       sealed tamper-evident bag numbered [X]"].
   2.2 The item is held at [LOCATION].
   2.3 The Key Holder [has been / has not been] informed of the
       contents.

3. WHAT THE KEY HOLDER MAY NOT DO
   The Key Holder shall not:
   (a) open, read, photograph, copy or transcribe the item,
       except as permitted under clause 4;
   (b) disclose the existence, location or contents of the item
       to any person, except as permitted under clause 4;
   (c) enter the contents into any computer, telephone, website
       or software;
   (d) use the item for the Key Holder's own benefit;
   (e) transfer the item to any other person, except under
       clause 5.

4. WHEN THE ITEM MAY BE RELEASED
   The Key Holder shall release the item only:
   (a) to the Principal, on request, at any time; or
   (b) on production of a certified copy of the Principal's death
       certificate, to [NAMED PERSON] or to the person then
       acting as executor or administrator of the Principal's
       estate; or
   (c) on [OTHER DEFINED TRIGGER, e.g. production of a medical
       certificate of incapacity, or a court order]; or
   (d) as directed by a court of competent jurisdiction.

5. IF THE KEY HOLDER CANNOT CONTINUE
   5.1 If the Key Holder is unable or unwilling to continue, they
       shall notify the Principal in writing and return the item
       to the Principal.
   5.2 If the Principal cannot be contacted within [PERIOD], the
       Key Holder shall [deposit the item with [SUBSTITUTE] /
       deliver it to [LAWYER]].
   5.3 The Key Holder shall inform [NAMED PERSON] of the
       existence of this appointment, so that it is not lost if
       the Key Holder dies.

6. STANDARD OF CARE
   The Key Holder shall keep the item as securely as they would
   keep a valuable item of their own, and in any event in a
   [safe / bank deposit box / locked container] at the location
   in clause 2.2.

7. NO LIABILITY FOR VALUE
   The Key Holder is not a trustee of, and assumes no
   responsibility for the value of, any assets to which the item
   may relate. The Key Holder's obligations are limited to safe
   custody and the restrictions in clause 3.

8. COMPENSATION
   The Key Holder acts [gratuitously / for [AMOUNT] per year].

9. TERMINATION
   The Principal may terminate this appointment at any time in
   writing, whereupon the Key Holder shall return the item within
   [PERIOD].

10. REVIEW
    The parties shall confirm in writing every [PERIOD] that this
    arrangement remains in force and that the item is intact.

11. GOVERNING LAW
    This Agreement is governed by the law of [JURISDICTION].

SIGNED:

Principal: __________________  Date: __________
Key Holder: _________________  Date: __________

Notes. Clause 5.3 is the one people forget, and it is the reason plans fail: the key holder dies and their family throws away an envelope nobody could explain. Clause 10 is equally important, since an unreviewed arrangement silently decays as devices are replaced. Never describe the contents in clause 2.1 with enough specificity to make the item a target.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

MULTISIGNATURE CO-HOLDERS AGREEMENT

Between: [NAMES AND DETAILS OF ALL PARTIES]

Date: [DATE]

1. THE ARRANGEMENT
   1.1 The parties jointly control a [M]-of-[N] multisignature
       wallet ("the Wallet").
   1.2 Each party holds one key. The allocation is recorded in
       Schedule 1.
   1.3 The wallet descriptor / configuration file is held by
       [EACH PARTY / [CUSTODIAN]] at [LOCATION], and each party
       acknowledges that the descriptor is necessary for recovery
       and must be preserved independently of the keys.

2. BENEFICIAL OWNERSHIP
   2.1 The funds in the Wallet are owned as follows:
       [NAME]: [X]%   [NAME]: [Y]%   [NAME]: [Z]%
   2.2 Holding a key does not confer beneficial ownership beyond
       the share in clause 2.1.

3. AUTHORISING A TRANSACTION
   3.1 Any party may propose a transaction by [METHOD], stating
       the amount, the destination address and the purpose.
   3.2 A transaction requires [M] signatures.
   3.3 [Optional: transactions above [AMOUNT] require the consent
       of all parties, regardless of the signing threshold.]
   3.4 Every destination address shall be verified by at least
       two parties through separate channels before signing.
   3.5 A test transaction shall be sent first for any transfer
       above [AMOUNT].

4. DUTIES OF EACH KEY HOLDER
   Each party shall:
   (a) keep their key secure and never disclose it;
   (b) never store their key with the descriptor in the same
       place;
   (c) notify the others immediately if their key is lost,
       compromised or suspected compromised;
   (d) participate in a recovery test every [PERIOD].

5. LOSS OR COMPROMISE OF A KEY
   5.1 On notice under clause 4(c), the parties shall promptly
       cooperate to move the funds to a newly generated wallet
       with a replacement key set.
   5.2 The costs of doing so are borne by [THE PARTY AT FAULT /
       all parties in proportion to their shares].

6. DEATH OR INCAPACITY OF A PARTY
   6.1 On the death of a party, their key shall be dealt with as
       provided in their will or estate arrangements, and their
       share under clause 2.1 forms part of their estate.
   6.2 The surviving parties shall cooperate with the deceased
       party's executor to give effect to clause 6.1.
   6.3 [Optional: the surviving parties may purchase the deceased
       party's share at a value determined under clause 8.]

7. WITHDRAWAL OF A PARTY
   7.1 A party may withdraw on [PERIOD] written notice.
   7.2 On withdrawal, the parties shall cooperate to transfer the
       withdrawing party's share to an address they nominate, and
       to re-establish the Wallet with a new key set.

8. VALUATION
   Where a share must be valued, it shall be valued by reference
   to [PRICE SOURCE] at [TIME] on the relevant date.

9. DEADLOCK
   If the parties cannot agree on a proposed transaction within
   [PERIOD], the matter shall be resolved under [MECHANISM: see
   Template 16].

10. RECORDS
    The parties shall maintain a shared record of all
    transactions, including transaction IDs and purposes.

11. GOVERNING LAW
    [JURISDICTION].

SIGNED by each party.

SCHEDULE 1: KEY ALLOCATION
[Party] - key [1] - device type [X] - backup location
[DESCRIPTION WITHOUT DISCLOSING CONTENTS]

Notes. Clause 1.3 is the sleeper. A correct set of keys with a lost descriptor produces an empty wallet and an heir who concludes the funds are gone. Clause 4(d), the periodic recovery test, is what converts this from a document into a working arrangement.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

COLLABORATIVE CUSTODY AGREEMENT

Between:
  CLIENT:   [NAME AND DETAILS]
  PROVIDER: [ENTITY NAME, REGISTERED NUMBER, ADDRESS]

Date: [DATE]

1. NATURE OF THE SERVICE
   1.1 The parties will establish a [M]-of-[N] multisignature
       wallet in which the Provider holds [NUMBER] key(s) and the
       Client holds [NUMBER] key(s).
   1.2 The Provider cannot move funds alone. Any spend requires
       at least [NUMBER] key(s) held by the Client.
   1.3 The parties intend that the Client retains beneficial
       ownership of all assets at all times.
   1.4 Clauses 1.2 and 1.3 record the factual arrangement and the
       parties' intention. They do not determine how the
       arrangement is characterised for regulatory, custody,
       licensing or tax purposes, which is a question of the
       applicable law and not of what the parties agree to call
       it.

2. THE PROVIDER'S OBLIGATIONS
   The Provider shall:
   (a) generate and hold its key securely, and never disclose it;
   (b) co-sign a transaction properly requested and verified in
       accordance with clause 3;
   (c) maintain the wallet descriptor and provide a copy to the
       Client on request and at least every [PERIOD];
   (d) not lend, pledge, rehypothecate or otherwise use any
       asset;
   (e) notify the Client without undue delay of any security
       incident affecting its key.

3. TRANSACTION REQUESTS AND VERIFICATION
   3.1 The Client may request co-signing by [METHOD].
   3.2 The Provider shall verify the request by [VERIFICATION
       PROCEDURE, e.g. video call, shared secret, pre-agreed
       questions].
   3.3 The Provider shall refuse to co-sign where verification
       fails.
   3.4 The Provider shall co-sign within [PERIOD] of successful
       verification.

4. WHAT THE PROVIDER WILL NOT DO
   4.1 The Provider shall not co-sign any transaction not
       requested and verified under clause 3.
   4.2 The Provider shall not act on instructions from any person
       other than the Client or a person authorised under
       clause 5.

5. INHERITANCE AND INCAPACITY
   5.1 The Client [has / has not] nominated [NAME] as the person
       entitled to act on the Client's death or incapacity.
   5.2 The Provider shall act on production of [SPECIFIED
       DOCUMENTS] and after verification under clause 3.2.
   5.3 The Provider shall not disclose the existence of the
       Client's account to any person before that point.

6. IF THE PROVIDER FAILS
   6.1 The Client acknowledges that the Client can recover the
       assets without the Provider, using the Client's own keys
       and the descriptor, provided the threshold is met.
   6.2 The Provider shall maintain arrangements ensuring the
       Client is notified and provided with the descriptor if the
       Provider ceases to operate.
   6.3 [Optional: the descriptor is deposited with [THIRD PARTY]
       as an independent backup.]

7. FEES
   [AMOUNT] per [PERIOD], payable [WHEN]. Non-payment does not
   entitle the Provider to withhold co-signing of a transaction
   returning assets to the Client.

8. LIABILITY
   8.1 The Provider is liable for [DEFINE].
   8.2 The Provider is not liable for loss of the Client's own
       keys or backups.
   8.3 [LIABILITY CAP, IF ANY.]

9. TERMINATION
   Either party may terminate on [PERIOD] notice. On
   termination, the Provider shall cooperate to move the assets
   to a wallet controlled solely by the Client, and shall
   provide the descriptor.

10. DATA
    The Provider shall process the Client's personal data only
    as necessary to provide the service, and shall retain it for
    no longer than [PERIOD] after termination, subject to legal
    retention obligations.

11. GOVERNING LAW
    [JURISDICTION].

SIGNED.

Before anything else: this document is written from the service provider's side. Holding a key for another person, and charging for it, may itself be a regulated activity where you are, depending on how the keys are held, what the provider can do alone, and whether it is done in the course of a business. Custody, safekeeping and wallet provision are licensed activities in a number of jurisdictions. That question concerns the provider's own position and is not answered by anything in this document. Establish it before offering the service, and before agreeing to receive it from someone who has not.

Notes. Clauses 6.1 to 6.3 are the ones to read hardest in any real provider's terms. If you cannot recover without the provider, this is not collaborative custody, it is custody. Clause 7's final sentence prevents a provider from holding your assets hostage over an unpaid invoice.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

MINING HOSTING AGREEMENT

Between:
  OWNER:    [NAME AND DETAILS]
  OPERATOR: [ENTITY NAME, REGISTERED NUMBER, ADDRESS]

Date: [DATE]

1. EQUIPMENT
   1.1 The Owner delivers to the Operator the equipment listed in
       Schedule 1 ("the Equipment"), identified by serial number.
   1.2 Title to the Equipment remains with the Owner at all times.
       The Operator has no lien, charge or right of retention over
       the Equipment except as expressly provided in clause 9.
   1.3 The Operator shall keep the Equipment identifiable and
       separate from its own property and that of other clients.

2. HOSTING SERVICES
   The Operator shall:
   (a) house the Equipment at [SITE ADDRESS];
   (b) supply electrical power up to [CAPACITY] kW;
   (c) provide cooling, network connectivity and physical security;
   (d) monitor the Equipment and perform basic maintenance;
   (e) notify the Owner of any failure within [PERIOD].

3. POWER AND FEES
   3.1 Power is charged at [RATE] per kWh [or: at cost plus [X]%,
       evidenced by the supplier's invoices].
   3.2 A hosting fee of [AMOUNT] per [unit/period] is payable.
   3.3 Invoices are issued [monthly] and payable within [PERIOD].
   3.4 [Price adjustment: the Operator may adjust the power rate
       on [PERIOD] notice if its own supply cost changes by more
       than [X]%. The Owner may terminate without penalty within
       [PERIOD] of such notice.]

4. UPTIME
   4.1 The Operator shall use [reasonable endeavours / best
       endeavours] to maintain uptime of at least [X]%, measured
       [monthly], excluding Excused Downtime.
   4.2 "Excused Downtime" means downtime caused by: scheduled
       maintenance notified [PERIOD] in advance and not exceeding
       [X] hours per month; grid curtailment; force majeure; or
       failure of the Equipment itself.
   4.3 If uptime falls below [X]%, the Owner is entitled to
       [service credit of [FORMULA] / termination without
       penalty].

5. CURTAILMENT
   5.1 The Operator may curtail operation where required by the
       grid operator or by [DEFINED CIRCUMSTANCES].
   5.2 The Operator shall notify the Owner of curtailment
       exceeding [PERIOD] and shall not charge power fees for
       curtailed periods.

6. MINING OUTPUT
   6.1 All Bitcoin mined by the Equipment belongs to the Owner.
   6.2 The Equipment shall point to [POOL / ADDRESS] as directed
       by the Owner, and the Operator shall not change the
       configuration without written instruction.
   6.3 [If the Operator receives any output: the Operator shall
       transfer it to the Owner's address [ADDRESS] within
       [PERIOD], and shall not commingle it with its own funds.]

7. ACCESS AND INSPECTION
   The Owner may inspect the Equipment on [PERIOD] notice during
   business hours, and may [remotely monitor via [METHOD]].

8. RISK, INSURANCE AND DAMAGE
   8.1 Risk of loss or damage passes to the Operator on delivery
       and remains with the Operator until collection.
   8.2 The Operator shall maintain insurance covering the
       Equipment to at least [AMOUNT], and shall provide evidence
       on request.
   8.3 The Operator is liable for damage caused by its failure to
       maintain the environmental conditions in clause 2.

9. TERMINATION AND RETURN
   9.1 Either party may terminate on [PERIOD] notice.
   9.2 On termination, the Operator shall make the Equipment
       available for collection within [PERIOD].
   9.3 The Operator may withhold the Equipment only for undisputed
       invoices overdue by more than [PERIOD], and only after
       [PERIOD] written notice.
   9.4 The Operator shall not sell, dispose of or repurpose the
       Equipment without a court order.

10. INSOLVENCY
    The Owner's title under clause 1.2 shall be asserted in the
    event of the Operator's insolvency. The Operator shall
    maintain records sufficient to identify the Owner's Equipment
    at all times.

11. GOVERNING LAW
    [JURISDICTION].

SIGNED:

Owner: ______________________  Date: __________
Operator: ___________________  Date: __________
          Name and position: [DETAILS]

SCHEDULE 1: EQUIPMENT
[Model] | [Serial number] | [Rated power] | [Delivery date]

Notes. Clauses 1.2, 1.3 and 10 together are what determine whether you get your machines back when a hosting company fails. Identifiability is the practical question: if your hardware cannot be distinguished from everyone else's in the insolvency, ownership on paper may not help you.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

MINING REVENUE SHARING AGREEMENT

Between:
  INVESTOR: [NAME AND DETAILS]
  OPERATOR: [NAME AND DETAILS]

Date: [DATE]

1. CONTRIBUTIONS
   1.1 The Investor contributes [AMOUNT] [CURRENCY] for the
       acquisition of equipment listed in Schedule 1.
   1.2 The Operator contributes [site, power contract, labour,
       expertise, DESCRIBE].

2. OWNERSHIP
   2.1 The equipment is owned by [INVESTOR / jointly in the
       proportions [X]:[Y]].
   2.2 This Agreement does not create a partnership, joint venture
       or company, and neither party may bind the other.
   [Note: whether this is legally effective depends on your
   jurisdiction. In several systems a profit-sharing arrangement
   may be characterised as a partnership regardless of what the
   document says, with consequences for liability and tax. Take
   advice.]

3. REVENUE SHARING
   3.1 Gross mining output shall be allocated: Investor [X]%,
       Operator [Y]%.
   3.2 [Alternatively: the Operator shall first deduct actual
       power and hosting costs, evidenced by invoices, and the
       net output shall be allocated [X]:[Y].]
   3.3 Allocation and distribution shall occur [weekly/monthly].
   3.4 The Investor's share shall be sent to [ADDRESS], notified
       in writing and verified by two channels.

4. COSTS
   4.1 Power and hosting costs are borne by [PARTY].
   4.2 Repairs and replacement parts are borne by [PARTY] up to
       [AMOUNT] per [PERIOD], and above that by agreement.
   4.3 The Operator shall provide monthly statements showing
       hashrate, uptime, output, costs and the allocation
       calculation.

5. TRANSPARENCY
   5.1 The Operator shall provide the Investor with read-only
       access to [pool account / monitoring dashboard].
   5.2 The Investor may audit the records on [PERIOD] notice, at
       the Investor's cost unless a discrepancy above [X]% is
       found.

6. TERM AND EXIT
   6.1 The term is [PERIOD], renewable by agreement.
   6.2 On termination, the equipment shall be [returned to the
       Investor / sold and the proceeds divided [X]:[Y]].
   6.3 Either party may terminate for material breach not
       remedied within [PERIOD] of written notice.

7. RISK
   The Investor acknowledges that mining revenue depends on
   factors outside either party's control, including network
   difficulty, the Bitcoin price and energy costs, and that the
   Operator gives no guarantee of return.

8. TAX
   Each party is responsible for its own tax position. The
   parties acknowledge that mining output may be taxable on
   receipt and that each has taken independent advice.

9. GOVERNING LAW
   [JURISDICTION].

SIGNED.

Before anything else: an arrangement in which one party provides money and relies on another party's efforts to generate a return is the pattern that securities regulation examines, in the United States and in many other systems. Calling it a revenue share, a partnership or a hosting agreement does not settle the question; the substance of the arrangement does. If money is being raised from people who will not operate anything, take advice on that before the arrangement is offered, not after.

Notes. Clause 2.2 deserves real attention. Profit-sharing arrangements are frequently recharacterised as partnerships, which can make each party liable for the other's debts and change the tax treatment entirely. Whether the clause works is a question of local law, not of drafting.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

PAYMENT IN BITCOIN

1. CURRENCY OF ACCOUNT AND CURRENCY OF PAYMENT
   1.1 The amounts payable under this Agreement are denominated
       in [CURRENCY] ("the Currency of Account").
   1.2 The parties agree that payment shall be made in Bitcoin
       ("the Currency of Payment").
   [Alternative: amounts are denominated in BTC, in which case
   delete clauses 2 and 3 and state the BTC amount directly.]

2. CONVERSION
   2.1 The amount of Bitcoin payable shall be calculated by
       dividing the invoiced amount in the Currency of Account by
       the rate published by [PRICE SOURCE] at [TIME]
       [TIMEZONE] on [the invoice date / the payment date].
   2.2 The payer shall state the rate used and the source on the
       remittance advice.

3. RATE VALIDITY WINDOW
   3.1 A quoted Bitcoin amount is valid for [PERIOD] from the
       time of quotation.
   3.2 If payment is not made within that period, the amount
       shall be recalculated at the rate prevailing at the time
       of payment, determined under clause 2.1.

4. PAYMENT ADDRESS AND VERIFICATION
   4.1 Payment shall be made to the address notified by the payee
       in writing.
   4.2 The payer shall verify the address through a second,
       independent channel before sending.
   4.3 The payee shall not change the payment address by email
       alone. Any change must be confirmed by [SECOND CHANNEL].
   4.4 The payer shall send a test transaction of [AMOUNT] and
       await written confirmation before sending the balance,
       for any payment exceeding [THRESHOLD].

5. WHEN PAYMENT IS COMPLETE
   Payment is complete when the transaction has [NUMBER]
   confirmations on the Bitcoin network. The payer bears the
   network fee, and the amount received net of fees must equal
   the amount due.

6. UNDER- AND OVERPAYMENT
   6.1 If the amount received is less than the amount due, the
       shortfall remains payable.
   6.2 If the amount received exceeds the amount due, the excess
       shall be [refunded within [PERIOD] / credited against the
       next invoice].

7. IRREVERSIBILITY AND MISDIRECTED PAYMENTS
   7.1 The parties acknowledge that Bitcoin transactions cannot
       be reversed.
   7.2 A payment sent to an address correctly notified by the
       payee under clause 4.1 discharges the payer's obligation,
       even if the payee has lost control of that address.
   7.3 A payment misdirected because of the payer's own error
       does not discharge the payer's obligation, and the amount
       due remains payable.

8. FAILURE OF THE PAYMENT METHOD
   If for any reason payment in Bitcoin becomes impossible or
   unlawful for either party, payment shall be made in the
   Currency of Account by [FALLBACK METHOD] within [PERIOD].

9. TAX AND ACCOUNTING
   Each party is responsible for its own tax treatment,
   including any gain or loss arising from the disposal of
   Bitcoin used to make or received in payment.

Notes. Clause 4.3 prevents the single commonest fraud in this area: an intercepted email announcing a change of payment address. Clause 1 matters conceptually: denominating in fiat and paying in Bitcoin is a very different deal from denominating in Bitcoin, and the parties should know which one they made.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

ADDENDUM TO EMPLOYMENT CONTRACT
Payment of part of remuneration in Bitcoin

Between:
  EMPLOYER: [NAME AND DETAILS]
  EMPLOYEE: [NAME AND DETAILS]

Supplemental to the employment contract dated [DATE].

1. ELECTION
   1.1 The Employee elects to receive [X]% of net remuneration,
       or [AMOUNT] per [PERIOD], whichever is lower, in Bitcoin.
   1.2 The election is voluntary and was made at the Employee's
       request.
   1.3 The Employee may revoke the election at any time on
       [PERIOD] written notice, and shall thereafter be paid
       entirely in [CURRENCY].

2. LEGAL MINIMUM PROTECTED
   2.1 Nothing in this Addendum reduces the Employee's gross
       remuneration, and all statutory entitlements continue to
       be calculated on the gross amount in [CURRENCY].
   2.2 Any part of remuneration that must by law be paid in legal
       tender shall be so paid, and the election in clause 1
       applies only to the remainder.
   [Note: many jurisdictions require wages to be paid in legal
   tender, or protect a minimum portion. Verify before using.]

3. TAX AND SOCIAL CONTRIBUTIONS
   3.1 All income tax and social contributions shall be
       calculated and withheld on the gross remuneration in
       [CURRENCY], in the ordinary way, before the election is
       applied.
   3.2 The election does not alter the Employee's tax position on
       the remuneration itself.
   3.3 The Employee is solely responsible for any tax arising
       from the subsequent holding or disposal of the Bitcoin
       received.

4. CONVERSION AND TIMING
   4.1 The Bitcoin amount shall be calculated using the rate
       published by [PRICE SOURCE] at [TIME] [TIMEZONE] on the
       payroll date.
   4.2 The Employer shall state the rate and source on the
       payslip, together with the equivalent amount in
       [CURRENCY].

5. DELIVERY
   5.1 The Employee shall notify a receiving address in writing
       and shall confirm it through [SECOND CHANNEL].
   5.2 The Employer shall not act on a change of address received
       by a single channel.
   5.3 The Employer's obligation is discharged on transfer to the
       notified address with [NUMBER] confirmations.

6. RISK
   6.1 The Employee acknowledges that the value of Bitcoin
       fluctuates and that the Employer gives no assurance as to
       its future value.
   6.2 The Employer bears no responsibility for the Employee's
       custody of the Bitcoin after transfer.

7. RECORDS
   The Employer shall provide, and retain for [PERIOD], records
   showing for each payment: the gross amount, deductions, the
   net amount, the rate used, the BTC amount and the transaction
   ID.

8. TERMINATION
   On termination of employment, any final payment shall be made
   in [CURRENCY] unless the parties agree otherwise in writing.

SIGNED.

Notes. Clause 2.2 is not optional decoration. A number of jurisdictions require wages to be paid in legal tender and treat an agreement to the contrary as void, sometimes with penalties for the employer. This template keeps the tax and statutory calculations entirely in fiat. That is a conservative design intended to reduce one category of payroll-compliance risk, not a guarantee of compliance anywhere.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

CONSULTING AGREEMENT

Between:
  CLIENT:     [NAME AND DETAILS]
  CONSULTANT: [NAME AND DETAILS]

Date: [DATE]

1. SERVICES
   The Consultant shall provide: [DESCRIBE SCOPE, DELIVERABLES
   AND ANY MILESTONES].

2. TERM
   From [DATE] until [DATE / completion of the Services].

3. FEES
   3.1 [AMOUNT] [per hour / per day / fixed fee], denominated in
       [CURRENCY].
   3.2 [Expenses: pre-approved expenses reimbursed at cost on
       production of receipts.]

4. PAYMENT IN BITCOIN
   [Insert Template 10 here, or reference it as a schedule.]

5. INVOICING
   The Consultant shall invoice [monthly / on milestones].
   Invoices are payable within [PERIOD]. Each invoice shall state
   the amount in [CURRENCY], the rate and source used, and the
   BTC amount payable.

6. INDEPENDENT CONTRACTOR
   6.1 The Consultant is an independent contractor and not an
       employee. The Consultant is responsible for their own
       taxes, social contributions and insurance.
   6.2 The Consultant may work for others and controls their own
       working methods, hours and location.
   [Note: whether a relationship is employment is decided by the
   substance, not the label. If the Client directs how, when and
   where the work is done, a court may find employment regardless
   of this clause. See the qualification discussion in the lessons.]

7. INTELLECTUAL PROPERTY
   7.1 [Deliverables belong to the Client on payment in full /
       the Consultant grants the Client a licence to [SCOPE].]
   7.2 The Consultant retains ownership of pre-existing materials
       and general know-how.

8. CONFIDENTIALITY
   8.1 Each party shall keep confidential all non-public
       information received from the other, shall use it only
       for the purposes of this Agreement, and shall not
       disclose it to any third party without prior written
       consent.
   8.2 This clause does not apply to information that is
       public through no breach of this Agreement, was already
       lawfully held, or must be disclosed by law.
   8.3 This clause survives termination for [PERIOD].

9. LIABILITY
   The Consultant's total liability is limited to [the fees paid
   under this Agreement / [AMOUNT]], except for [fraud, wilful
   misconduct, death or personal injury, or anything that cannot
   be limited by law].

10. TERMINATION
    Either party may terminate on [PERIOD] notice. The Client
    shall pay for Services performed up to termination.

11. GOVERNING LAW AND DISPUTES
    [JURISDICTION]. [See Template 16.]

SIGNED.

Notes. Clause 6 is the risk clause, not clause 9. Misclassification of contractors is aggressively pursued in many jurisdictions, and the consequences (back taxes, social contributions, employment rights) fall mainly on the client.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

BITCOIN SAVINGS CLUB AGREEMENT

Between the persons listed in Schedule 1 ("the Members").

Date: [DATE]

1. PURPOSE
   1.1 The Members agree to pool contributions to purchase and
       hold Bitcoin for their own benefit.
   1.2 The Club is not a business, does not accept members of the
       public, does not manage money for anyone other than the
       Members, and does not solicit contributions.
   [Note: pooling other people's money to invest is a regulated
   activity in nearly every jurisdiction. This template is drafted
   for a closed group of participants who all take part. If you
   are managing funds for passive investors, you probably need a
   licence. Take advice before doing anything.]

2. CONTRIBUTIONS
   2.1 Each Member contributes [AMOUNT] per [PERIOD].
   2.2 Contributions are recorded in the register at Schedule 2.
   2.3 A Member may cease contributing on [PERIOD] notice,
       retaining their accrued share.

3. SHARES
   3.1 Each Member's share is proportionate to their total
       contributions, adjusted for the price at which each
       contribution was deployed.
   3.2 The register shall record, for each contribution: the
       date, the amount, the BTC purchased, the price and the
       resulting share.

4. CUSTODY
   4.1 The pooled Bitcoin is held in a [M]-of-[N] multisignature
       wallet with keys held by [NAMED MEMBERS].
   4.2 [Insert Template 06, or reference it, for the custody
       arrangements.]
   4.3 No single Member may move funds alone.

5. DECISIONS
   5.1 Routine purchases are made [on a fixed schedule / by
       decision of [NUMBER] Members].
   5.2 Any sale, and any change to this Agreement, requires
       [unanimity / [X]% of shares].
   5.3 Meetings shall be held [PERIOD] and minuted.

6. WITHDRAWAL
   6.1 A Member may withdraw on [PERIOD] written notice.
   6.2 On withdrawal the Member receives their share, transferred
       in Bitcoin to an address they nominate, verified by two
       channels.
   6.3 [Any withdrawal fee or notice period to protect the
       remaining Members.]

7. DEATH OF A MEMBER
   7.1 A deceased Member's share forms part of their estate.
   7.2 The remaining Members shall cooperate with the executor.
   7.3 Each Member undertakes to inform their executor of the
       existence of this Agreement and of their share, and to
       keep a copy with their estate documents.

8. RECORDS AND TRANSPARENCY
   The register shall be maintained by [MEMBER] and shall be
   available to every Member at all times. Every transaction ID
   shall be recorded.

9. TAX
   Each Member is responsible for their own tax position on
   their own share. The Club does not provide tax advice.
   Members acknowledge that a taxable event may arise on
   contribution, on withdrawal, or both, depending on the
   jurisdiction.

10. NO GUARANTEE
    No Member guarantees any return to any other Member. The
    value of the pooled assets may fall.

11. DISSOLUTION
    The Club may be dissolved by [unanimity / [X]%], whereupon
    the assets shall be distributed to Members in proportion to
    their shares.

12. GOVERNING LAW
    [JURISDICTION].

SIGNED by each Member:

Name: __________  Signature: __________  Date: __________
Name: __________  Signature: __________  Date: __________
Name: __________  Signature: __________  Date: __________

SCHEDULE 1: MEMBERS
SCHEDULE 2: CONTRIBUTION REGISTER
[Date] | [Member] | [Amount] | [Price] | [BTC acquired] | [TXID]

Before anything else: the line between a savings club among friends and an unlicensed collective investment scheme is drawn by whether the members participate in decisions and whether anyone is managing money on behalf of passive contributors. Pooling other people's money and deciding what to do with it is a regulated activity in most systems, and getting it wrong is a regulatory matter rather than a contractual one. Establish the position before money is collected.

Notes. Read clause 1's note twice. The line between a friends' savings club and an unlicensed fund is drawn by whether members participate in decisions and whether anyone is managing money on behalf of passive investors. Getting it wrong is a regulatory offence, not a contractual problem.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

SOURCE OF FUNDS DECLARATION

I, [FULL LEGAL NAME], of [ADDRESS], born [DATE OF BIRTH],
declare as follows.

1. PURPOSE
   This declaration is provided to [RECIPIENT] in connection with
   [TRANSACTION / ACCOUNT / REQUEST REFERENCE].

2. ASSETS CONCERNED
   [AMOUNT] BTC, currently held at [wallet / platform,
   IDENTIFIED WITHOUT DISCLOSING KEYS].

3. ORIGIN
   The assets were acquired as set out in the schedule below.
   For each acquisition I state the date, the method, the
   counterparty or platform, the amount paid, and the supporting
   document attached.

   [DATE] | [METHOD] | [PLATFORM/COUNTERPARTY] | [AMOUNT PAID] |
   [BTC ACQUIRED] | [EXHIBIT NUMBER]

4. UNDERLYING SOURCE OF WEALTH
   The funds used to make those acquisitions derived from:
   [SELECT AND DESCRIBE: employment income, business profits,
   sale of property, sale of a business, inheritance, gift,
   savings accumulated over [PERIOD], other].
   Supporting documents are attached as Exhibits [X] to [Y].

5. DOCUMENTS ATTACHED
   Exhibit 1: [e.g. bank statements showing transfers to the
              platform, [DATES]]
   Exhibit 2: [platform transaction history export]
   Exhibit 3: [employment contract / payslips / tax returns]
   Exhibit 4: [sale contract / inheritance documents]
   Exhibit 5: [on-chain transaction IDs linking the acquisition
              to the current holding]

6. GAPS
   [State honestly any acquisition for which documentation is
   incomplete, and why. For example: "The platform used for the
   acquisition of [DATE] ceased operating in [YEAR] and I no
   longer have access to its records. Exhibit [X] is the bank
   statement showing the payment to it."]

7. DECLARATIONS
   7.1 The assets were lawfully acquired.
   7.2 The assets do not derive, directly or indirectly, from any
       criminal activity.
   7.3 I am the beneficial owner of the assets and am not acting
       on behalf of any undisclosed person.
   7.4 I am not subject to any sanctions measure.
   7.5 The information in this declaration is true and complete
       to the best of my knowledge.

Signed: ______________________  Date: __________

[Notarisation or certification if required by the recipient]

Notes. Clause 6 is the one people are tempted to omit, and omitting it is the mistake. Compliance teams cross-check documents against each other; an honest, specific gap handles far better than a smooth narrative the attachments do not support. Never fabricate or backdate anything: that converts a compliance question into fraud.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

DECLARATION OF CONTROL OF A BITCOIN ADDRESS

I, [FULL LEGAL NAME], of [ADDRESS], declare as follows.

1. ADDRESS
   The Bitcoin address [ADDRESS] ("the Address") is under my
   sole control.

2. METHOD OF PROOF
   [SELECT ONE OR MORE]
   (a) Signed message. I have signed the following message with
       the private key corresponding to the Address:
         Message: "[MESSAGE TEXT INCLUDING DATE AND RECIPIENT]"
         Signature: [SIGNATURE]
   (b) Test transaction. I have sent [AMOUNT] BTC from the
       Address to [RECIPIENT ADDRESS], transaction ID [TXID], on
       [DATE].
   (c) Extended public key. I provide the extended public key
       [XPUB] from which the Address derives, permitting
       verification without any ability to spend.

3. NATURE OF CONTROL
   3.1 I hold [the private key / [M] of [N] keys in a
       multisignature arrangement] necessary to authorise
       transactions from the Address.
   3.2 I am the beneficial owner of the assets at the Address and
       am not holding them for any undisclosed person.
   3.3 [If applicable: the other keys are held by [DESCRIBE
       WITHOUT IDENTIFYING SENSITIVE DETAIL].]

4. NO DISCLOSURE OF KEYS
   Nothing in this declaration discloses, and I have not been
   asked to disclose, any private key, seed phrase or passphrase.
   I will not provide such material to any person, and any
   request that I do so should be treated as fraudulent.

5. DECLARATION
   The above is true to the best of my knowledge.

Signed: ______________________  Date: __________

Notes. Clause 4 is there for you, not the recipient. Legitimate institutions never need your seed phrase, and a request for one is definitionally an attempted theft. Method (a), a signed message, is the strongest proof and reveals nothing. Method (c), an xpub, proves control but discloses your entire transaction history for that account, so use it only where necessary.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

GOVERNING LAW AND DISPUTE RESOLUTION

1. GOVERNING LAW
   This Agreement, and any non-contractual obligations arising
   out of or in connection with it, are governed by the law of
   [JURISDICTION], without regard to its conflict of laws rules.

2. NEGOTIATION
   Before commencing any proceedings, the parties shall attempt
   in good faith to resolve the dispute through discussion
   between [named representatives], for a period of [PERIOD]
   from written notice of the dispute.

3. MEDIATION [OPTIONAL]
   If negotiation fails, the parties shall attempt mediation
   under the rules of [MEDIATION BODY], before a single mediator,
   within [PERIOD]. Costs shall be shared equally.

4. FINAL RESOLUTION
   [CHOOSE ONE]

   OPTION A: COURTS
   4.1 The courts of [JURISDICTION] have exclusive jurisdiction.
   4.2 The parties waive any objection based on forum.
   [Suitable where both parties are in the same country, or where
   a judgment in that country can realistically be enforced where
   the other party's assets are.]

   OPTION B: ARBITRATION
   4.1 Any dispute shall be finally resolved by arbitration under
       the rules of [ARBITRAL INSTITUTION].
   4.2 The tribunal shall consist of [one / three] arbitrator(s).
   4.3 The seat of arbitration shall be [CITY, COUNTRY].
   4.4 The language of the arbitration shall be [LANGUAGE].
   4.5 The award shall be final and binding, and judgment on it
       may be entered in any court of competent jurisdiction.
   [Suitable for cross-border agreements, where an arbitral award
   is generally easier to enforce abroad than a court judgment.]

5. INTERIM RELIEF
   Nothing in this clause prevents either party from applying to
   any competent court for urgent interim or protective relief,
   including to preserve assets or evidence.

6. COSTS
   [The unsuccessful party shall bear the costs of the
   proceedings / each party shall bear its own costs.]

7. LANGUAGE
   This Agreement is executed in [LANGUAGE]. [If a translation
   exists: in the event of inconsistency, the [LANGUAGE] version
   prevails.]

8. NOTICES
   8.1 Notices shall be in writing and sent to the addresses in
       [CLAUSE], and shall be deemed received:
       (a) if delivered by hand, on delivery;
       (b) if sent by registered post, [X] days after posting;
       (c) if sent by email, on confirmed receipt, and not merely
           on sending.
   8.2 A party shall notify the other of any change of address
       within [PERIOD].

9. SURVIVAL
   This clause survives termination of the Agreement.

Notes. Clause 8.1(c) matters far more than it looks. Deeming an email received on sending means a margin call, a default notice or a termination can take effect while you are on holiday. Insist on confirmed receipt wherever a notice has serious consequences. And choose between the two options in clause 4 deliberately: a judgment you cannot enforce where the assets are is worth nothing.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

BITCOIN LOAN AGREEMENT

Between:
  LENDER:   [NAME AND DETAILS]
  BORROWER: [NAME AND DETAILS]

Date: [DATE]

1. THE LOAN
   1.1 The Lender lends [AMOUNT] BTC ("the Principal").
   1.2 The Principal is denominated and repayable in Bitcoin.
       No fiat amount is owed at any point.
   1.3 The Principal shall be transferred to the address
       notified by the Borrower, verified under clause 6.

2. INTEREST
   2.1 Interest accrues at [RATE]% per annum on the outstanding
       Principal, calculated in BTC.
   2.2 Interest is payable [in BTC, monthly in arrears / in BTC
       on repayment].

3. REPAYMENT
   3.1 The Borrower shall repay [AMOUNT] BTC plus accrued
       interest on [DATE].
   3.2 Repayment is made in Bitcoin. The Borrower is not
       discharged by tendering fiat, unless the Lender agrees in
       writing at the time.
   3.3 Early repayment is permitted [without penalty / subject to
       [X] days' notice].

4. ACKNOWLEDGEMENT OF PRICE RISK
   4.1 The parties acknowledge that the fiat value of the
       Principal may rise or fall substantially between advance
       and repayment.
   4.2 The Borrower acknowledges that if the price rises, the
       fiat cost of repayment increases correspondingly, and
       that the Borrower bears that risk entirely.
   4.3 The Lender acknowledges that the Lender bears the risk of
       a fall.
   [This clause exists to prevent a later argument that the
   parties did not understand what they agreed. In some
   jurisdictions a grossly one-sided loan may be attacked on
   grounds such as usury, lesion or unfair terms. Take advice
   before lending or borrowing large amounts this way.]

5. SECURITY [OPTIONAL]
   [If the loan is secured, insert the collateral and enforcement
   clauses from Template 03, adapted so that the debt is
   BTC-denominated and the enforcement threshold is expressed in
   BTC rather than by loan-to-value.]

6. ADDRESS VERIFICATION
   6.1 Each party shall notify its receiving address in writing
       and confirm it through a second independent channel.
   6.2 A test transaction of [AMOUNT] BTC shall precede any
       transfer, and shall be confirmed in writing.

7. EVENTS OF DEFAULT
   (a) failure to repay on the due date;
   (b) failure to pay interest within [PERIOD] of the due date;
   (c) [OTHER].

8. CONSEQUENCES OF DEFAULT
   8.1 On default, the whole outstanding Principal and accrued
       interest becomes immediately payable in BTC.
   8.2 Default interest accrues at [RATE]% per annum in BTC.
   8.3 The Lender may recover reasonable enforcement costs.

9. IF REPAYMENT IN BITCOIN BECOMES IMPOSSIBLE
   If repayment in Bitcoin becomes impossible or unlawful for
   the Borrower, the Borrower shall pay the fiat equivalent of
   the outstanding BTC amount, determined by [PRICE SOURCE] at
   [TIME] on the due date, within [PERIOD].

10. TAX
    Each party is responsible for its own tax position. The
    parties acknowledge that lending, repayment and interest may
    each be treated as taxable events in some jurisdictions, and
    that each has taken independent advice.

11. GOVERNING LAW AND DISPUTES
    [JURISDICTION]. [See Template 16.]

SIGNED.

Before anything else: the same point as Template 03 applies here. Lending as a regular activity, or to consumers, commonly requires authorisation and attracts consumer credit rules, and those obligations sit with the lender. Denominating the loan in Bitcoin does not remove them.

Notes. Clause 4 is the most important in the document. A BTC-denominated loan can become ruinous for a borrower if the price multiplies, and courts in several systems will look hard at whether the borrower understood that. Clause 9 is the fallback nobody thinks about until it matters.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

WRITTEN RESOLUTION OF THE BOARD OF DIRECTORS
[COMPANY NAME], [REGISTERED NUMBER]

Date: [DATE]
Present / signing: [NAMES]

BACKGROUND
(A) The Board has considered the acquisition and holding of
    Bitcoin as a treasury asset of the Company.
(B) The Board has reviewed: the Company's constitutional
    documents; the Treasury Policy at Appendix 1; the risk
    assessment at Appendix 2; the accounting analysis at
    Appendix 3; the tax analysis at Appendix 4; and the
    custody arrangements at Appendix 5.
(C) The Board has considered whether the proposed acquisition is
    within the Company's objects and powers, and is consistent
    with the directors' duties, including the duty to act in the
    manner consistent with the directors' duties under the law
    applicable to the Company.

IT IS RESOLVED THAT:

1. AUTHORITY
   1.1 The Company is authorised to acquire and hold Bitcoin as
       a treasury asset, up to a maximum of [AMOUNT] or [X]% of
       [defined measure], whichever is lower.
   1.2 The Treasury Policy at Appendix 1 is adopted.

2. AUTHORISED SIGNATORIES
   2.1 Acquisitions and disposals up to [AMOUNT] may be
       authorised by [ROLE].
   2.2 Above that amount, authorisation of [NUMBER] directors is
       required.
   2.3 No single individual may hold the ability to transfer the
       Company's Bitcoin alone.

3. CUSTODY
   3.1 The Company's Bitcoin shall be held in a [M]-of-[N]
       multisignature arrangement, with keys allocated as set out
       in Appendix 5.
   3.2 [Or: held with [CUSTODIAN] under the agreement approved at
       Appendix 5.]
   3.3 The wallet descriptor or configuration shall be held by
       [ROLES] and a copy deposited with [THIRD PARTY].
   3.4 No private key, seed phrase or passphrase shall be
       recorded in any Company minute, email or shared drive.

4. RECORDS AND REPORTING
   4.1 The [ROLE] shall maintain a register of every acquisition
       and disposal, recording date, counterparty, amount, price,
       fees and transaction ID.
   4.2 The [ROLE] shall report holdings and their valuation to
       the Board [quarterly].
   4.3 Valuation shall use [PRICE SOURCE] at [TIME] on the
       reporting date, consistently applied.

5. KEY PERSON AND CONTINUITY
   5.1 The Board shall ensure that no single person's
       unavailability prevents the Company from accessing its
       Bitcoin.
   5.2 A recovery test shall be conducted every [PERIOD] and
       reported to the Board.

6. REVIEW
   The Treasury Policy shall be reviewed at least annually and
   on any material change of circumstances.

7. DECLARATIONS
   Each director confirms that they have disclosed any interest
   in the matters resolved above, and that no director has an
   interest requiring them to abstain other than as recorded.

Signed by each director:

_________________  _________________  _________________

Notes. Recital (C) helps document the directors' decision process. Acquiring a volatile asset without a documented decision process is where personal liability arises, not in the acquisition itself. Clause 3.4 is where the practical risk sits: minutes and shared drives are exactly where key material must never appear.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

DIGITAL ASSET CUSTODY POLICY
[COMPANY NAME] | Version [X] | Approved [DATE] | Owner: [ROLE]

1. SCOPE
   This policy applies to all digital assets held by the Company
   and to every person with any role in their custody, including
   employees, officers and contractors.

2. PRINCIPLES
   2.1 No single person shall be able to move Company assets
       alone.
   2.2 No key material shall exist in any system not approved
       under this policy.
   2.3 Every movement of assets shall be authorised, recorded
       and reconciled.
   2.4 The Company shall be able to recover its assets without
       the participation of any one individual.

3. ROLES
   Key Holders:     [ROLES]. Hold signing devices.
   Initiator:       [ROLE]. Proposes transactions.
   Approver:        [ROLE]. Approves before signing.
   Reconciler:      [ROLE]. Independent of the above. Verifies
                    balances against the register.
   Policy Owner:    [ROLE]. Maintains this policy.
   No individual may hold more than one of Initiator, Approver
   and Reconciler.

4. STORAGE STANDARDS
   4.1 Signing devices shall be [SPECIFY TYPE AND STANDARD].
   4.2 Devices and backups shall be stored at [SEPARATE
       LOCATIONS], never together.
   4.3 Backups shall be [medium], stored in [container] at
       [location], and inspected every [PERIOD].
   4.4 The wallet descriptor shall be stored separately from all
       keys, with a copy held by [EXTERNAL PARTY].

5. PROHIBITED ACTS
   No person shall:
   (a) enter any seed phrase or private key into any computer,
       telephone, browser, cloud service, password manager,
       messaging application or printer;
   (b) photograph key material;
   (c) transmit key material by any means, to anyone, for any
       reason, including to the Company's own IT function or to
       any person claiming to require it;
   (d) store key material in any Company document, minute,
       ticket or shared drive;
   (e) use Company devices or addresses for personal holdings.

6. TRANSACTION PROCEDURE
   6.1 The Initiator prepares a request stating amount,
       destination address, purpose and supporting documentation.
   6.2 The destination address is verified by two people through
       independent channels, and the verification is recorded.
   6.3 The Approver authorises.
   6.4 Key Holders sign to the threshold.
   6.5 A test transaction precedes any transfer above [AMOUNT].
   6.6 The Reconciler confirms completion and updates the
       register.

7. LEAVERS AND ROLE CHANGES
   7.1 On any Key Holder leaving or changing role, the Company
       shall promptly generate a new wallet and migrate the
       assets, using an entirely new key set.
   7.2 Removing a person's access is not sufficient. The keys
       they held must be treated as compromised.
   7.3 Migration shall be completed within [PERIOD] of the
       leaving date.

8. INCIDENTS
   8.1 Any suspected loss, theft, compromise or unauthorised
       access shall be reported to [ROLE] immediately.
   8.2 The Company shall migrate assets to a new wallet without
       waiting for confirmation of the suspicion.
   8.3 Incidents shall be logged and reported to the Board.

9. RECOVERY TESTING
   9.1 A full recovery from backups shall be tested every
       [PERIOD], using a wallet holding a nominal amount.
   9.2 The test shall be performed by a person who did not
       create the backup.
   9.3 Results shall be recorded and reported to the Board.

10. AUDIT
    The register shall be reconciled to on-chain balances
    [monthly] by the Reconciler, and reviewed [annually] by
    [internal audit / external auditor].

11. REVIEW
    This policy shall be reviewed at least annually.

Acknowledged by:
Name: __________ Role: __________ Signature: __________ Date: ______

Notes. Clause 7.2 is the one companies resist and the one that matters. A departing key holder may have copied their key, and there is no way to know. Rotation is the only real remedy, and it must be a scheduled process rather than a judgment call about whether the person is trustworthy.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

POWER OF ATTORNEY FOR DIGITAL ASSETS

I, [FULL LEGAL NAME], of [ADDRESS], born [DATE OF BIRTH]
("the Principal"), appoint:

  ATTORNEY:           [NAME, ADDRESS, DATE OF BIRTH]
  SUBSTITUTE ATTORNEY: [NAME, ADDRESS, DATE OF BIRTH]

1. WHEN THIS POWER TAKES EFFECT
   [CHOOSE ONE]
   (a) Immediately, and continues if I lose capacity.
   (b) Only on my loss of capacity, evidenced by [SPECIFIED
       MEDICAL CERTIFICATION].

2. SCOPE OF AUTHORITY
   The Attorney is authorised to:
   (a) identify, access and manage my digital assets;
   (b) communicate with any exchange, custodian, platform or
       service provider on my behalf;
   (c) transfer assets between wallets I control, for security
       or maintenance purposes;
   (d) sell assets where necessary to meet my living costs, care
       costs, debts or tax liabilities;
   (e) file tax returns and deal with tax authorities in respect
       of those assets;
   (f) engage professional advisers at my expense.

3. LIMITS ON AUTHORITY
   The Attorney shall NOT:
   (a) make gifts of my assets, except [DEFINE NARROWLY OR
       DELETE];
   (b) transfer assets to the Attorney personally or to any
       person connected with the Attorney;
   (c) use my assets as security for any borrowing;
   (d) [OTHER LIMITS].

4. ASSETS COVERED
   4.1 This power extends to all digital assets I hold, whether
       or not known to the Attorney at the date of this
       document.
   4.2 Information about where those assets are and how they are
       accessed is NOT contained in this document. It is held
       as described in my Instructions to my Executor dated
       [DATE], and by [KEY HOLDER] under the appointment dated
       [DATE].

5. NO DISCLOSURE OF KEY MATERIAL
   Nothing in this document authorises any person to require me
   or any key holder to disclose a seed phrase, private key or
   passphrase to the Attorney. Access shall be given by
   transferring custody of the relevant device or backup, not by
   disclosing its contents.

6. DUTIES OF THE ATTORNEY
   The Attorney shall:
   (a) act in my best interests and not their own;
   (b) keep my assets separate from their own;
   (c) keep full records of every decision and transaction,
       including transaction IDs;
   (d) account to [NAMED PERSON / on request] every [PERIOD];
   (e) not delegate, except to a professional adviser for a
       specific task.

7. SUBSTITUTE
   If the Attorney is unable or unwilling to act, the Substitute
   Attorney shall act on the same terms.

8. REVOCATION
   I may revoke this power at any time while I have capacity, by
   written notice to the Attorney.

9. GOVERNING LAW
   [JURISDICTION].

Signed: ______________________  Date: __________

Witness 1: ___________________  Name and address: [DETAILS]
Witness 2: ___________________  Name and address: [DETAILS]

Attorney's acceptance:
I accept this appointment and the duties in clause 6.
Signed: ______________________  Date: __________

Notes. Clause 5 embodies the central design principle: an attorney should be given custody, not secrets. Handing over a device is reversible in a way that disclosing a seed phrase never is. And note the warning at the top harder than usual: this is the one template on this page where using it unmodified is most likely to produce a void document.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

CHARITABLE GIFT AND RECEIPT: SKELETON

PART 1: DECLARATION BY THE DONOR

I, [DONOR NAME], of [ADDRESS], give to [CHARITY NAME],
[REGISTERED CHARITY NUMBER], of [ADDRESS] ("the Charity"),
[AMOUNT] BTC ("the Gift").

1. TRANSFER
   Date: [DATE]  |  Transaction ID: [TXID]
   Receiving address: [ADDRESS]
   Confirmations: [NUMBER]

2. VALUATION
   2.1 The value of the Gift at the date and time of transfer was
       [AMOUNT] [CURRENCY].
   2.2 Determined by reference to [PRICE SOURCE] at [TIME]
       [TIMEZONE] on [DATE], being [RATE] per BTC.
   2.3 The parties record this valuation as the agreed value for
       the Charity's records and the Donor's reporting.

3. NATURE OF THE GIFT
   3.1 The Gift is made voluntarily and gratuitously.
   3.2 The Donor has received and will receive no goods,
       services, benefit or consideration in return.
   [Or, where a benefit was received: "The Donor received the
   following benefit: [DESCRIBE], with a value of [AMOUNT]."
   Many tax systems reduce or deny relief where any benefit is
   received, so this must be stated accurately.]
   3.3 The Gift is [unrestricted / restricted to [PURPOSE]].

4. SOURCE
   The Bitcoin given was lawfully acquired by the Donor and does
   not derive from any unlawful activity. The Donor has provided
   source of funds information at Appendix 1 [where requested].

5. NO CONDITIONS
   The Gift is not subject to any condition [other than the
   restriction in clause 3.3], and the Donor retains no interest
   in it or control over it.

6. TAX
   6.1 Each party is responsible for its own tax position.
   6.2 The Donor acknowledges that the availability of any relief
       depends on the Donor's own circumstances and jurisdiction,
       and that the Charity has given no tax advice.

PART 2: RECEIPT BY THE CHARITY

[CHARITY NAME] acknowledges receipt of the Gift described above.

7. CONFIRMATIONS BY THE CHARITY
   7.1 The Charity is a [registered charity / recognised
       not-for-profit entity] under the law of [JURISDICTION],
       registration number [NUMBER].
   7.2 The Charity received the Gift on [DATE] at the address
       stated.
   7.3 The Charity provided no goods or services in return
       [or: provided the benefit described in clause 3.2].
   7.4 The Charity will apply the Gift [to its general purposes /
       to the restricted purpose in clause 3.3].
   7.5 The Charity's policy is to [hold / convert on receipt]
       digital asset donations.

8. GOVERNING LAW
   This declaration is governed by the law of [JURISDICTION].

Donor:   ______________________  Date: __________
Charity: ______________________  Date: __________
         Name and position: [DETAILS]

Notes. Clause 3.2 decides whether relief is available in most systems, and it is the clause donors most often get wrong by forgetting a dinner, a naming, or a ticket received in return. Clause 2 matters because the valuation must be contemporaneous: reconstructing a price years later, after the charity has converted, is difficult and looks self-serving.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

EQUIPMENT SALE AGREEMENT

Between:
  SELLER: [NAME AND DETAILS]
  BUYER:  [NAME AND DETAILS]

Date: [DATE]

1. THE EQUIPMENT
   Listed in Schedule 1, identified by model and serial number.

2. PRICE AND PAYMENT
   2.1 Price: [AMOUNT] [CURRENCY], or [AMOUNT] BTC.
   2.2 [If paid in Bitcoin, insert Template 10.]
   2.3 Payment is due [WHEN], and is deemed made when
       irreversibly received.

3. CONDITION AND DESCRIPTION
   3.1 The Equipment is sold used, in the condition described in
       Schedule 1.
   3.2 The Seller warrants that, at the time of despatch:
       (a) each unit powers on and hashes;
       (b) the hashrate of each unit is not less than [X]% of its
           rated hashrate, measured over [PERIOD];
       (c) no unit has been immersion cooled, water damaged or
           repaired other than as disclosed in Schedule 1;
       (d) no unit has been modified beyond firmware updates
           disclosed in Schedule 1;
       (e) no unit is subject to any lock, lease, financing or
           third-party claim.
   3.3 The Seller has disclosed all known defects in Schedule 1.

4. TITLE
   4.1 The Seller warrants that it owns the Equipment free of any
       lien, charge or retention of title.
   4.2 Title passes to the Buyer on [payment in full / delivery],
       whichever is later.

5. TESTING AND ACCEPTANCE
   5.1 The Buyer may test the Equipment within [PERIOD] of
       delivery.
   5.2 The Buyer shall notify any non-conformity with clause 3.2
       within that period, with supporting evidence.
   5.3 If notified, the Seller shall [replace the unit / refund
       the pro-rata price / repair], at [the Seller's / the
       Buyer's] election.
   5.4 Absent notice within the testing period, the Equipment is
       deemed accepted.

6. DELIVERY AND RISK
   6.1 Delivery: [collection by the Buyer at [LOCATION] /
       despatch by the Seller to [ADDRESS]].
   6.2 Delivery costs and insurance are borne by [PARTY].
   6.3 Risk passes on [delivery / collection].
   6.4 The Equipment shall be packed in a manner adequate for
       transport of the type used.

7. NO WARRANTY BEYOND CLAUSE 3
   Save as stated in clause 3, the Equipment is sold as is. No
   warranty is given as to profitability, future hashrate,
   remaining useful life or resale value.
   [Note: in consumer sales, and in some commercial sales, this
   exclusion may be void. Where the Buyer is a consumer, do not
   rely on it.]

8. EXPORT AND IMPORT
   Each party is responsible for its own compliance with export,
   import, customs and duty requirements. [PARTY] shall provide
   [documentation].

9. GOVERNING LAW AND DISPUTES
   [JURISDICTION]. [See Template 16.]

SIGNED:

Seller: ______________________  Date: __________
Buyer:  ______________________  Date: __________

SCHEDULE 1
Model | Serial | Rated hashrate | Measured hashrate | Hours run |
Known defects | Repairs disclosed | Firmware

Notes. Clause 3.2(c) is specific for a reason: immersion-cooled and water-damaged units are the two categories most often sold without disclosure, and both materially shorten remaining life. The "hours run" column in Schedule 1 is the single most useful field and the one sellers most often omit.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

INVOICE

From:      [NAME / ENTITY], [ADDRESS]
           [TAX / VAT NUMBER, IF APPLICABLE]
To:        [CLIENT NAME], [ADDRESS]
           [CLIENT TAX NUMBER, IF APPLICABLE]

Invoice number:  [NUMBER]
Invoice date:    [DATE]
Due date:        [DATE]

DESCRIPTION                          QTY    RATE      AMOUNT
[Service or goods]                   [X]   [RATE]   [AMOUNT]
                                     ---------------------------
                          Subtotal              [AMOUNT] [CCY]
                          [Tax at X%]           [AMOUNT] [CCY]
                          TOTAL DUE             [AMOUNT] [CCY]

PAYMENT IN [CURRENCY]
  [Bank details, or reference to details held separately]

PAYMENT IN BITCOIN (optional)
  BTC amount due:     [AMOUNT] BTC
  Rate used:          [RATE] [CCY] per BTC
  Rate source:        [SOURCE], [TIME] [TIMEZONE], [DATE]
  Quote valid until:  [DATE, TIME]
  Payment address:    [ADDRESS]

  Terms:
  1. The invoice is denominated in [CURRENCY]. The BTC figure
     above is a conversion, valid until the time stated.
  2. If payment is made after the quote expires, the BTC amount
     will be recalculated at the rate published by the same
     source at the time of payment, and any shortfall remains
     payable.
  3. The payer bears the network fee. The amount received net of
     fees must equal the BTC amount due.
  4. Payment is complete on [NUMBER] confirmations.
  5. This payment address will not change. Any communication
     purporting to change it should be verified by telephone on
     [NUMBER] before payment. We will never notify a change of
     address by email alone.
  6. Please quote invoice number [NUMBER] when confirming
     payment, and provide the transaction ID.

Overdue amounts carry interest at [RATE] from the due date.

Notes. Point 5 belongs on every invoice you ever send. Invoice fraud through intercepted email and a substituted payment address is a common way businesses lose money to crypto payments, and one sentence on the invoice prevents most of it.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

INFRASTRUCTURE HOSTING AGREEMENT

Between:
  CUSTOMER: [NAME AND DETAILS]
  PROVIDER: [ENTITY, REGISTERED NUMBER, ADDRESS]

Date: [DATE]

1. SERVICES
   The Provider shall provide: [dedicated server / colocation /
   virtual machine] at [LOCATION], with the specification at
   Schedule 1, including power, cooling, connectivity and
   physical security.

2. THE CUSTOMER'S USE
   2.1 The Customer may install and operate software of its
       choice, subject to clause 3.
   2.2 The Customer is solely responsible for the configuration,
       security and lawfulness of what it runs.

3. ACCEPTABLE USE
   The Customer shall not use the Services for any unlawful
   purpose, and shall comply with [ACCEPTABLE USE POLICY].
   [Verify that the Provider's policy does not prohibit the
   operation of blockchain nodes, which some general hosting
   terms do, sometimes in a clause about "cryptocurrency
   activity" aimed at mining.]

4. AVAILABILITY
   4.1 The Provider shall use [reasonable / best] endeavours to
       maintain availability of [X]%, measured [monthly].
   4.2 Scheduled maintenance shall be notified [PERIOD] in
       advance and shall not exceed [X] hours per month.
   4.3 Failure to meet the availability target entitles the
       Customer to [service credit of [FORMULA]].

5. DATA AND ACCESS
   5.1 The Provider shall not access, copy or inspect the
       Customer's data or software except as strictly necessary
       to provide the Services or as required by law.
   5.2 The Provider shall notify the Customer of any legal demand
       for access, before complying, unless prohibited from
       doing so.
   5.3 The Customer acknowledges that the Provider has physical
       access to the hardware and that the Customer should
       therefore not store any key material or sensitive secret
       on it.

6. NO KEY MATERIAL
   The Customer confirms it will not store private keys, seed
   phrases or passphrases on the hosted infrastructure without
   independent hardware protection, and the Provider accepts no
   responsibility for any such material.

7. SUSPENSION
   7.1 The Provider may suspend the Services only for: non-
       payment after [PERIOD] written notice; a material breach
       of clause 3; or an emergency threatening the Provider's
       network.
   7.2 The Provider shall notify the Customer before suspension
       where practicable, and shall restore promptly once the
       cause is resolved.

8. FEES
   [AMOUNT] per [PERIOD], payable [WHEN]. Price changes require
   [PERIOD] notice, and the Customer may terminate without
   penalty within [PERIOD] of such notice.

9. TERMINATION AND DATA RETURN
   9.1 Either party may terminate on [PERIOD] notice.
   9.2 On termination, the Provider shall make the Customer's
       data available for [PERIOD] and shall then securely
       delete it.
   9.3 The Provider shall not withhold the Customer's data as
       security for unpaid fees.

10. LIABILITY
    [LIMIT], excluding [fraud, wilful misconduct, and anything
    that cannot be limited by law].

11. GOVERNING LAW
    [JURISDICTION].

SIGNED:

Customer: ____________________  Date: __________
Provider: ____________________  Date: __________
          Name and position: [DETAILS]

SCHEDULE 1: SPECIFICATION

Notes. Clause 3's bracketed note catches a real problem: many general hosting terms prohibit "cryptocurrency activity" in language aimed at mining, and that wording can be read to cover a node, which does no mining at all. Check the acceptable use policy before signing, not after. Clause 5.3 and clause 6 state the obvious that people ignore: anyone with physical access to a machine can, given time, extract what is on it.

Educational skeleton Not a legal document. Adapt every clause, resolve every bracket, and have it reviewed where you live.

LETTER OF INTENT

Between: [PARTY A] and [PARTY B]
Date: [DATE]

1. PURPOSE
   This letter records the parties' current intentions in
   relation to [DESCRIBE THE PROPOSED TRANSACTION]. It is
   intended to guide the negotiation of definitive documents.

2. BINDING AND NON-BINDING PROVISIONS
   2.1 Clauses 3 to 6 are NOT legally binding and create no
       obligation on either party to enter into any transaction.
   2.2 Clauses 7 to 12 ARE legally binding and take effect on
       signature.
   [This split is the single most important part of the document.
   Be explicit. In some jurisdictions a document expressed in
   definite terms may bind the parties despite a label to the
   contrary, and in several systems a party who breaks off
   negotiations in bad faith may be liable regardless.]

--- NON-BINDING TERMS ---

3. THE PROPOSED TRANSACTION
   [DESCRIBE: sale, investment, joint venture, acquisition.]
   Amount: [AMOUNT] BTC / [AMOUNT] [CURRENCY]
   Pricing mechanism: [DESCRIBE, including price source and time]
   Structure: [DESCRIBE]

4. CONDITIONS
   Completion would be subject to: satisfactory due diligence;
   [regulatory approval]; [board approval]; [third-party
   consents]; execution of definitive documents.

5. INDICATIVE TIMETABLE
   Due diligence to [DATE]; first drafts by [DATE]; signing
   target [DATE]; completion target [DATE].

6. COSTS
   Each party bears its own costs, whether or not the
   transaction completes.

--- BINDING TERMS ---

7. CONFIDENTIALITY
   The existence and contents of this letter, and all
   information exchanged in connection with it, are
   confidential. Each party shall use them only to evaluate the
   proposed transaction and shall not disclose them without
   prior written consent, except where disclosure is required
   by law or to professional advisers bound by equivalent
   obligations.

8. EXCLUSIVITY
   Until [DATE], [PARTY] shall not solicit, negotiate with or
   enter into any agreement with any third party in respect of a
   transaction of the type described in clause 3.

9. NO KEY MATERIAL
   Neither party shall request or disclose any seed phrase,
   private key or passphrase at any stage. Where proof of
   holdings is required, it shall be given by signed message or
   extended public key under Template 15.

10. DUE DILIGENCE ACCESS
    [PARTY] shall provide reasonable access to [DEFINE SCOPE],
    subject to clause 7.

11. GOOD FAITH
    The parties shall negotiate in good faith, without obligation
    to reach agreement.

12. GOVERNING LAW AND DISPUTES
    [JURISDICTION]. [See Template 16.] This clause applies to
    the binding provisions and to any dispute about whether a
    provision is binding.

13. TERMINATION
    This letter lapses on [DATE] unless extended in writing. The
    binding provisions survive for [PERIOD].

Signed:
[PARTY A] ______________  [PARTY B] ______________

Notes. Clause 2 is why this document exists. Term sheets are routinely signed with everyone assuming nothing is binding, and then someone relies on the exclusivity or breaches the confidentiality. Say exactly which clauses bind. Clause 12's final sentence is a small refinement that saves a great deal of argument later: it makes the dispute clause cover the question of what was binding in the first place.