TAKT Terms of Service

Version b0b0cd367e5d

Effective: 4 October 2026.

1. Parties and business use.

1.1. Provider: ABX DEVELOPMENT LLP, a limited liability partnership registered in Scotland (United Kingdom) under number SO301872; address: 39/5 Granton Crescent, Edinburgh, EH5 1BN, United Kingdom; legal notices: [email protected]. The services are provided under the name TAKT; payments are received by the Provider.

1.2. The services are offered for business purposes. The Client is the business, or the individual acting in the course of a business, whose legal name and business address are given in the dashboard before the first purchase; they appear on the Client's invoices. A person who accepts these Terms on behalf of an organisation confirms that they are authorised to bind it. Consumer purchases are not offered under these Terms.

2. Subject. The Provider speeds up the hot Rust code submitted by the Client and delivers a build (a static or dynamic library or an executable) with a report on the measurements and the equivalence check. The source code of the accelerated version, the optimiser and the methods are not delivered, except for the encrypted source escrow and its conditional release under clause 8. The Client keeps its rights in the submitted materials and confirms that it has the authority needed for the agreed processing and delivery; it grants the Provider a limited right to copy, compile, modify and execute those materials solely to perform the services, subject to the NDA, the DPA and the retention period.

3. Measurement passport. Before work starts, the passport fixes the platform, the CPU model and frequency, the tool versions, the benchmark, the hashes of the sources and inputs, the hash of the encrypted hidden inputs and the number of lines of hot code, and, for acceptance, the metric, its aggregation, the threshold, the run protocol, the permitted environmental variation and the functional-equivalence checks (which outputs, state and effects must be identical). All commitments apply only under the conditions of the passport.

4. Speed-up. For a baseline measurement B greater than zero and a measurement C of the delivered build, the speed-up factor is B/C and the speed-up is 100 × (B/C − 1) per cent; the reduction of time or cost, 100 × (1 − C/B) per cent, is a different quantity. Unless the order states otherwise, Level 1 prices use the speed-up of median cycle counts on the Provider's reference platform, in basis points: floor(10,000 × B/C) − 10,000. For Level 1 pricing, the Client's release build and any selected level-0 build of the same code are measured in the same session as the delivered build. B is the lower of their median cycle counts; if no level-0 recipe applies, B is the median cycle count of the Client's release build in that session. A paid build must pass the agreed equivalence checks; a speed-up alone is not acceptance. Unless the passport states otherwise, those checks require the build's output on the passport inputs and the hidden inputs to be identical byte for byte to the output of the original code. For NaNs produced by floating-point arithmetic, differences in payload bits alone are permitted only where both results are allowed by Rust for the original operations and the target specified in the passport. This exception does not apply to output NaN encodings explicitly set or preserved by the original code, or to differences in any other output, state or effects required to match under the passport. The passport may require exact NaN payloads as well. No gain that has not been measured is promised.

5. Balance, prices and payment.

5.1. Settlements are made through the Client's balance in the dashboard; the balance is kept in US dollars. The Client tops it up by the methods available in the dashboard (bank transfer against an invoice, card and other payment services); funds are credited once the payment has been received. A top-up invoice for a bank transfer is issued in US dollars, euros or pounds sterling: the amount in euros or pounds is calculated at the exchange rate when the invoice is issued and is valid until the date stated in it; the balance is credited with the amount in US dollars stated in the invoice.

5.2. The balance records paid funds (top-ups) and bonus funds (promo codes, bonuses, compensation). Bonus funds are spent first. Bonus funds pay only for the Provider's services and are not paid out. Releasing a hold or refunding a service restores the paid and bonus parts originally used, unless the order expressly provides otherwise; a refund does not turn bonus funds into paid funds.

5.3. Unused paid funds are paid back on request through the dashboard or [email protected]. The Provider initiates an approved payback within ten business days of receiving the information it needs, normally to the original payer by the original payment method; the payment provider's processing time is additional, and any other method, currency conversion or third-party charge is agreed with the Client beforehand. The Provider deducts no undisclosed fee.

5.4. The binding price is the total shown in the offer that the Client accepts in the dashboard, including its currency and any disclosed taxes or fees; for a trial it is fixed when the trial starts. Viewing a report is not a purchase. Later changes to the price table do not change an accepted offer.

5.5. The base level is free for hot code of up to 2,000 lines.

5.6. Level 1 is performed before payment: the Client sees the measured result and decides whether to buy it at the price of the offer. A speed-up below 10 per cent (1,000 basis points under clause 4) is not charged.

5.7. Level 2 and the CI subscription are provided only under a separate order accepted by the Client that sets out the price, the timetable, the measurable minimum, the acceptance procedure, the refund table, cancellation and the remedies for failure to deliver; without such an order nothing is debited for them. For the CI subscription the order also fixes the monthly release limit, the eligibility of releases and the acceptance protocol. The subscription lasts twelve months and does not renew automatically. For a month with N eligible releases within the plan limit, of which F fail the agreed threshold, the compensation is (annual fee / 12) × F / N, and none if N is zero; at the Client's choice, set in the dashboard, it is credited as bonus funds or the subscription is extended by F / N of that month's days, rounded up to whole days.

5.8. Promo codes and bonuses are credited as bonus funds on the terms of the particular promo code or bonus (amount, period of validity, number of uses). The Client may apply each promo code no more than once.

5.9. The Client may come through a referral link or a promo code of the Provider's distributor. The Provider pays the distributor out of its own funds; this does not affect the Client's prices or balance.

6. Line count. The price tier is determined by the number of lines of the Client's code executed when the benchmark of the passport is run on the open inputs, according to llvm-cov, under the rules published on the website.

7. Acceptance. The Client checks the delivered build under the acceptance protocol of the passport (clause 3). The passport defines the supported input domain and material preconditions; the recorded test inputs do not exhaust that domain unless expressly agreed before payment. If the Client notifies the Provider within twelve months after delivery of a reproducible difference on an input within that domain, under the passport conditions, in outputs, state or effects required to match, the Provider delivers a corrected build meeting the agreed acceptance conditions within 30 calendar days after receiving the information reasonably necessary to reproduce the difference. Differences expressly permitted by clause 4 or the passport are not defects for this purpose. If the Provider does not deliver that correction in time, it refunds the price paid for the affected build within ten business days, in accordance with clauses 5.2 and 5.3. For a CI subscription, the order fixes the price attributable to each build before payment. This remedy does not exclude other available claims, to which clause 9 applies.

8. Licence. On payment of the price, or on delivery of a build supplied free of charge, the Provider grants the Client a perpetual, worldwide, non-exclusive licence to run and reproduce the delivered build, to integrate it into the Client's products and services and to distribute it in binary form as part of those products. The build contains no licence check, expiry date, remote switch or network call added by the Provider, and it keeps working without any service of the Provider. Standalone resale of the build or of the Provider's technology is not included. The optimiser is not delivered. Where source escrow is included, the transformed source code is delivered only in the encrypted form described below, and the Client obtains it in clear only on release under that arrangement. Otherwise, transformed source code is not delivered. Third-party components remain subject to their applicable licences. The Provider identifies the components on request and supplies, with the delivery, any notices or other materials that those licences require it to provide. No right granted here overrides third-party rights; if the required terms cannot be met within the agreed delivery model, the affected build is not supplied unless the parties agree a compliant alternative. The Provider records the checksum (SHA-256) of every build it delivers against the order. Source escrow. Source escrow is available for any order at the Client's written request made before payment. It is provided as an escrow box: a bootable system image prepared for that order alone, which the Client runs at its own cost in a virtual machine with a TPM on a platform agreed for the order, and which gives the Client the transformed source code only when a release event under this clause has occurred. The escrow box rider published at https://taktcycles.com/legal/escrow-rider.html forms part of every order with escrow and prevails over any conflicting term of the order. The rider version and the platform are recorded for the order before payment, and escrow agreed for an order is unaffected by later changes. The image contains: the transformed source code of the delivered build with the instructions needed to rebuild it, encrypted with a key generated for that order alone; a manifest stating the SHA-256 checksum of the unencrypted source and of each source file and whether it is unchanged from the source code the Client submitted, transformed by the Provider or added by it; the build environment of the order; and the release rule of this clause. The Client receives the image with its SHA-256 checksum and may inspect all of its contents except the encrypted source. Before issuing the image, the Provider rebuilds the delivered build from that source in the build environment of the order, following the included instructions, and issues the image only if the result is identical to the delivered build, byte for byte. The order specifies, before payment, the objectively identifiable event that starts the five-business-day provisioning period. Within five business days after that event, the Provider provisions the escrow image in an account it controls, under the procedure recorded for the order and clause 3 of the rider, with exclusive control of the deployment and receiving path so that no other party can substitute the image or endpoint during provisioning. It verifies the agreed image and boot configuration through the platform control plane and binds that verification to the channel receiving the key before transmitting it; the image then seals the order key to that virtual machine's TPM and the recorded boot measurements. The Provider then transfers the account to the Client, who takes exclusive control under clause 3 of the rider, rotating credentials and access paths and removing every Provider principal. Server-authentication material that the Provider could retain is replaced, or the Client establishes a trusted resource-bound channel that does not rely on that material, as that clause permits. From the acceptance boot required by that clause, over a channel bound to the recorded virtual machine and boot, the Client independently verifies the running image and runs the box's checks before signing the acceptance. The applicable trust model and protection requirements, including confidentiality of the virtual machine's memory and TPM from whichever party operates it and the requirements for later platform changes, are recorded in the Schedule under clauses 2 and 3 of the rider. This procedure does not establish that the order key has never been known to the Provider; a Provider-blind secret requires a separate protocol. The image accepts only the commands described in the rider; no one, including the Provider, can otherwise log in to it. At any time the Client can use those commands to confirm that the sealed key opens the encrypted source and that the source rebuilds the delivered build byte for byte; they show checksums and results, not the source. If either check fails on an image run as the rider requires, the Provider issues and provisions a corrected image at its own cost. The image gives the Client the source when it finds, from the public register of Companies House and from the public repository https://github.com/abx-takt/takt-heartbeat, that: the Provider's status is dissolved, in liquidation, administration, receivership, insolvency proceedings or a voluntary arrangement, converted or closed, or removed; no valid heartbeat issued within the last 90 days is present; the repository has been deleted or not public for 14 consecutive days; or a validly signed heartbeat dated more than one hour after the decision time established under the rider is present. The Provider publishes in that repository, at least every seven days, a heartbeat stating that it operates its service, signed with its heartbeat key, and does not publish heartbeats while it does not provide the service. The rider defines a valid heartbeat and how the image establishes time. While the image cannot obtain consistent answers from those sources, it makes no decision. If the Provider is wound up, enters insolvency proceedings or ceases to provide the service and the image does not give the Client the source, the Provider gives the Client the order key, or the source, on request. The Provider keeps the order key in confidence for as long as the escrow of the order lasts and uses it only to provision images for that order and as this clause requires. The sealed key opens only with the TPM of the virtual machine in which it was provisioned, and only under the measured boot of that image. Deleting that virtual machine or its TPM, or a change of the platform that alters those measurements, makes the sealed key permanently unusable. While the Provider provides the service, it provisions a replacement for the same order at the Client's request, as the rider states; after that, keeping the virtual machine and its TPM is the Client's responsibility. The Client runs the image only on the agreed platform, does not read or attempt to read the memory or TPM state of that virtual machine, and does not attempt to obtain the source or the order key from the image other than through its commands. On release, the Client may use the source code only to maintain, correct and rebuild that build for the use licensed in this clause, and the NDA continues to apply to it. The Provider's retained delivery package and working materials remain subject to the DPA's existing retention and deletion rules. Delivery does not extend those periods. The Client is responsible for retaining its own escrow files.

9. Liability. Nothing limits liability for fraud, for death or personal injury caused by negligence, or any liability that cannot be limited by law. The duties to pay back unused paid funds, to release holds and to make agreed refunds are not limited by this clause. Subject to that, as between the Provider and the Client, the general cap is the fees paid or payable for the affected order. For claims for breach of confidentiality or data-protection obligations, a separate cap applies instead of the general cap: the greater of three times those fees and GBP 50,000. These contractual caps do not limit rights that individuals or regulators have independently under applicable law. Neither party may recover twice for the same loss.

10. Versions and notices. The dashboard records which versions of these Terms, the NDA, the DPA and the Trial Agreement the Client accepted and when; a later version does not change the price, licence or acceptance conditions of an order already accepted. The Trial Agreement governs the trial procedure, the DPA the processing of personal data and the NDA confidentiality. Notices are given through the dashboard and to the account's email address; legal notices to the Provider go to [email protected]. A business day is a day other than a Saturday, a Sunday or a public holiday in Scotland.

11. Governing law and jurisdiction. These Terms, the NDA, the DPA and the Trial Agreement are governed by the law of Scotland, and the courts of Scotland have exclusive jurisdiction, without prejudice to clause 8 of the Trial Agreement, to either party's right to seek interim relief in any court and to mandatory rights that apply despite this choice.