Basket, 0 items
AccountLegal · version 1.2 · 14 September 2026
What we collect, why, who sees it, where it is held, how long it is kept, and what you can ask us to do about it.
Today
These three tables describe how the site currently works, read directly from the code that runs it rather than written by hand. They are the factual half of this notice: what leaves your browser, what is kept on your device, and what your browser contacts. The numbered sections below are the other half — what we do with information, why, and for how long.
The one form on this site (contact, and the ambassador application) sends the following to /api/enquiry. One row is not sent by you at all — the server derives it from the request itself.
| Field | Sent by you? | What it is |
|---|---|---|
| type | Yes | Which kind of enquiry this is (general, product, COA, complaint, ambassador application). |
| name | Yes | The name typed into the form. |
| Yes | The email address typed into the form — used only to reply. | |
| subject | Yes | The subject line typed or pre-filled. |
| message | Yes | The message body typed into the form. |
| website | Yes | A honeypot field, invisible to a person. Empty on every genuine submission. |
| meta | Yes | Answers to any extra question fields the specific form variant adds. On the ambassador application that is the mobile number you give us; the accounts you would post from are sent as the message. |
| consent | Yes | The stored consent claim ({ documentId, documentVersion, textHash }), or null if the visitor never confirmed the notice on this device — see the vt-labs.ruo-consent-claim.v1 row above. |
| sign-in token (request header, only when signed in) | Yes | Sent only if you are signed in to an account when you send the form: a short-lived sign-in token in the request header, not in the form body. The server checks it and saves your account’s internal id with the message, so the conversation appears on your account page. The token itself is not stored, and if it is missing or cannot be checked the message is saved without an account link. |
| caller IP (hashed) | No — server-derived | The browser does not send this as a form field — the server reads the request’s own IP address, salts and SHA-256-hashes it, and stores that hash under `rate_limits` to count submissions per origin for one hour. The raw address is never stored; the hash cannot be reversed back to it. This exists purely to slow down automated abuse of the form. |
12 items of browser storage, all on your own device — none of these are sent anywhere unless the description below says so.
| Key | Kind | Holds | If cleared |
|---|---|---|---|
| vt-admin-rail-collapsed | localStorage | The literal string "1" when the signed-in admin has collapsed the left navigation rail on this device; "0" when expanded. | The rail opens expanded again on the next visit. Nothing else is affected. |
| vt-labs.ruo-acknowledged.v1 | localStorage | The date and time the research-use and age notice was cleared on this device by entering a date of birth that meets the minimum age — for example "2026-09-03T09:14:22.000Z". | The notice shows again on the next page load, and asks for a date of birth again. |
| vt-labs.ruo-date-of-birth.v1 | localStorage | The date of birth entered at the research-use notice, as a plain date — for example "1990-04-23". Only written when the date entered meets the minimum age; a date that does not is never written. | The notice shows again on the next page load, and asks for a date of birth again. |
| vt-labs.ruo-consent-claim.v1 | localStorage | A small record naming the notice, the version of it, and a hash of its text — the browser’s claim of which wording of the research-use + age notice it showed when the visitor confirmed. No personal data: it is a hash of static site copy, not of anything the visitor typed. | No functional loss. A form submitted afterwards simply carries no consent claim — the server accepts the message either way and records no verified consent for it. |
| vtl.cart.v1 | localStorage | A JSON object mapping SKU to quantity. No price, no product name, no line total. | The basket is empty on the next visit. Nothing else is affected. |
| firebaseLocalStorageDb | indexedDB | The signed-in session (tokens, refresh state) when someone IS signed in. Opened empty the moment the page loads, on every route: it exists even for a visitor who has never seen a sign-in form. | Signs the browser out of any Firebase session, the same as using a private window. No effect on a visitor who was never signed in. |
| vtl.referral-code.v1 | cookie | The normalised referral code this browser arrived under — e.g. "JANE10" — and nothing else. No ambassador identity, no rate, no money figure, no visitor identity. The code is a label the server resolves; on its own it says only which link was followed. | The visitor is simply not attributed on their next order. Nothing else changes — no page breaks, no price moves, and the customer’s own discount is unaffected because that comes from the code they type, not from this cookie. |
| vtl.cookie-consent.v1 | localStorage | Your answer to the cookie question: which optional categories you allowed, the version of the question you were asked, and when you answered. Nothing about you, and no record of anything you did on the site. | You are asked again on the next page load, and nothing optional is written in the meantime — an absent answer is read as "not allowed", never as "allowed". |
| _ga | cookie | A randomly generated number identifying this browser to Google Analytics, and the time it was first generated. A second cookie is set alongside it whose name begins “_ga_”, holding the same kind of value for this site’s own analytics property. Neither holds your name, your email address, your delivery address or anything you typed into a form. | Nothing on the site changes and no price moves. Your next visit is counted as a new one rather than a returning one. |
| firebase-heartbeat-database | indexedDB | The SDK’s own record of which Firebase products/versions this page has loaded. | No visible effect on the site. |
| vt-labs.account-marketing-not-saved.v1 | localStorage | The date and time your marketing-email answer, given when you created your account, failed to save on the server — for example "2026-09-04T09:14:22.000Z". Written only when that happens; never written on an ordinary sign-up. | No effect on your account. If your marketing preference genuinely was not saved, account settings would say only that you have not been asked before, rather than that the save failed — the setting itself is unaffected either way. |
| vt-labs.announcement-dismissed.v1 | localStorage | The date and time you closed the announcement strip at the top of the page on this browser — for example "2026-09-09T09:14:22.000Z". Nothing else: no identifier, nothing about you, and no record of what you looked at. Written only if you press its close button; if you never close it, nothing is written at all. | The announcement strip appears again on the next page load, and can be closed again. Nothing else is affected — no price moves, no basket changes, and nothing you have told the site is lost. |
| Host | Why |
|---|---|
| fonts.googleapis.com | Requests the stylesheet listing the two web fonts (Inter, JetBrains Mono). |
| fonts.gstatic.com | Serves the actual font files the stylesheet above references. |
| www.googletagmanager.com | Serves the Google Analytics script itself. Requested only after you turn on the Analytics cookie category — never before. |
| www.google-analytics.com | Receives the analytics measurements described in the Analytics cookie category. Contacted only after you turn that category on — never before. |
The first two hosts above are contacted on every page, for fonts. The two Google Analytics hosts are contacted only if you have turned on the “Analytics” cookie category — if you have not, the Google Analytics code is never loaded and neither host is contacted at all. There is no advertising pixel on this site and no host above is one. Visits to an ambassador’s referral link are counted separately, described above; that count is handled by this site’s own backend and is sent to nobody else.
Contents
R&R Life Science Ltd is the controller of the information described in this notice — it decides what is collected and why. Voltranis Labs and R&R Peptides are trading names of that company, not separate entities.
| Registered name | R&R Life Science Ltd |
|---|---|
| Trading as | Voltranis Labs and R&R Peptides — unregistered trading styles of the company above, not separate legal entities |
| Company number | 17331722 |
| Company type | Private company limited by shares |
| Registered in | Wales |
| Registrar | the Registrar of Companies for England and Wales, Companies House, Cardiff |
| Incorporated | 10 July 2026 |
| Registered office | 8 Pleasant View, Treharris, CF46 6SF, United Kingdom |
| VAT number | None published |
Anything in this notice — a question, a request about your information, a complaint — reaches us through the contact page. That form is the channel we monitor; a message sent through it is given a reference and lands in the same place as everything else. We have not appointed a data protection officer, because the law does not require this company to have one.
It covers information we hold about people who use this website: visitors, people who send us a message, people who order, people who hold an account, and ambassadors. It also covers the small amount of information kept on your own device by the site itself, which is listed in the first section above.
It does not cover other websites. Where this site links out, the site you arrive at has its own notice and we have no control over it.
Nothing here is collected because it might one day be useful. Each row exists because something specific cannot be done without it.
| When | What is collected |
|---|---|
| When you send us a message | The name, email address, subject and message you type, which kind of enquiry it is, and the answers to any extra questions on that form — the table above lists them field by field, read from the form itself. If you have confirmed the research-use notice on that device, the fingerprint of the wording you saw travels with the message. |
| When you place an order | Your name and email address; the delivery address you give (recipient name, an optional company name, the address lines, town, an optional county, the postcode and the country, which has to be in Great Britain), an optional telephone number for the carrier and an optional note; what you ordered and how many; the price our own server worked out for it; and the reference and status of the order. Where you pay by card, we also keep the payment reference and payment status our card payment provider gives back to us — never the card number, expiry date or security code, which are entered on that provider’s own payment page and never reach this site. The date of birth you entered at the research-use notice is sent with the order so our server can work out your age itself rather than take your browser’s word for it; it is used for that check and then discarded. What we keep against the order is that the check was made and that it passed — not the date. |
| When you confirm the research-use condition | Which document you were shown, its version, a fingerprint of the exact wording that was on your screen, and the time our server recorded the confirmation. See section 5. |
| When you sign for an order | The signature you draw, stored as an image against that order. See section 5. |
| When you open an account | Your email address and a password, handled by Google’s Firebase Authentication. We never see your password — it is not stored in a form we can read. Sign-in times and whether the address has been verified are held with it. |
| When you apply to the ambassador programme | Your application arrives through the contact form, so it is the same information as a message — with two additions the form asks for and this notice names rather than leaving to the general wording: a mobile number, and the social media accounts you would be posting from. If you are accepted, we then hold your agreement, the code issued to you, the orders attributed to it and the amounts earned and paid. |
| When you follow an ambassador's referral link | That the link was opened — a running count for that link — and roughly how many different people opened it that day, both credited to the ambassador who owns it. The “roughly” figure comes from a one-way fingerprint built in part from your network address and your browser’s own identifying string, salted so that it changes every single day — the fingerprint from your visit today cannot be matched to the fingerprint from any other day, by us or by anyone. Your network address and that identifying string are never themselves stored; only that day-scoped fingerprint is. It exists for one purpose — telling “the same visitor, twice today” apart from “two different visitors” — and it is used for nothing else. How long it is kept is a separate question, and the retention table below answers it honestly rather than leaving you to infer a short life from a narrow purpose. This happens only on the referral link’s own landing page — nothing else on the site counts a visit. We do not call this anonymous: because it is built from your network address, UK data protection law counts it as personal information about you, even though we cannot read your address back out of it. |
| When anyone uses the site at all | The browser storage listed in the table above, which stays on your own device, and a fingerprint of the network address a form submission came from — salted and hashed, never the address itself — used only as a counter to slow down automated abuse. Google, which hosts the site for us, keeps its own operational logs of requests. |
We do not ask for, and have no use for, information about anyone’s health. Please do not send it to us. If a message arrives containing it, we remove it from the record rather than keep it.
UK data protection law requires a lawful basis for each purpose. These are ours, purpose by purpose.
| Purpose | Lawful basis |
|---|---|
| Answering a message you send us | Our legitimate interests — replying to someone who has chosen to contact us. Where the message is about ordering, it is also steps taken at your request before a contract. |
| Taking, checking and fulfilling an order | Performance of our contract with you, or steps taken at your request before entering into one. |
| Keeping the research-use agreement and the signature attached to an order | Our legitimate interests — being able to show, afterwards and reliably, the condition on which research materials were supplied and what the person ordering confirmed. In a regulated sector that record protects both sides. |
| Keeping order, payment and accounting records | Our legal obligations, including company and tax record-keeping. |
| Running your account, if you open one | Performance of our contract with you. |
| Running the ambassador programme and paying what is earned | Performance of our contract with the ambassador, and our legal obligations for records of payments made. |
| Counting clicks on an ambassador's referral link | Our legitimate interests — an ambassador and we both need to know whether their link is actually being followed, which is what the programme uses to decide who to keep active. It is limited to that one narrow question, counts clicks rather than people, and is never used to build a profile of anyone. |
| Slowing down automated abuse of the forms | Our legitimate interests — keeping the site usable and its records trustworthy. This is why a fingerprint of a network address is counted for an hour. |
| Running and securing the website itself | Our legitimate interests — operating a website that works and can be maintained. |
Where the basis is our legitimate interests, we have weighed those interests against your rights and consider them proportionate — each one is narrow, and none involves building a profile of anyone. You can object to any of them: see section 9.
Research materials are supplied on one condition, set out in the terms of supply and on the research use only page. Because that condition is the whole basis of the supply, an order records what you were shown and what you confirmed.
The records this site creates — enquiries, orders, agreements, signatures — are held in Google’s Firestore database and processed by code running in Google’s europe-west2 (London) region. That was a deliberate choice at the time the project was set up: the company is in the United Kingdom and its records stay there.
Two things are handled outside that arrangement, and it is fair to be plain about them.
Where information is processed outside the United Kingdom, it is under the data protection terms in our agreement with Google, which include the UK Addendum to the European Commission’s standard contractual clauses — the transfer safeguard UK law recognises for this. You can ask us for more detail through the contact page.
Card payments are a third matter, and a separate one from the arrangement above. Payment card details are typed directly into SumUp’s own hosted payment page — never into a form on this site — so we do not receive, see or store your card number, expiry date or security code at any point; what we hold is the payment reference and payment status SumUp gives back to us. We have not yet confirmed where SumUp processes payment data, or the transfer safeguard that applies if that is outside the United Kingdom, and we will complete this section with that detail once we have it from SumUp.
A single blanket period would be no answer at all — a message and an order record are not the same thing. These are the periods, by category.
| What | How long |
|---|---|
| Messages you send, and our replies | Two years from the last message in the exchange, then deleted. A message that turns into an order is kept with that order instead. |
| Order records — what was ordered, the address it went to, the price and the status | Six years from the end of the financial year the order falls in. That is what company and tax record-keeping requires, and it is also the period in which a contract claim can be brought in England and Wales. |
| The research-use agreement and the signature attached to an order | Kept with the order they belong to, for the same six years, and deleted with it. They are evidence of that order and are not held separately or for longer. |
| Account records | For as long as the account is open. Ask us to close it and the account is deleted within thirty days — except that orders already placed stay in the order records above, because we are required to keep them. |
| Ambassador records — the agreement, the code, attributed orders and payments | Six years from the end of the financial year in which the last payment was made, for the same record-keeping reasons. |
| The abuse counter (a salted fingerprint of a network address) | One hour. The counter resets on a rolling one-hour window and nothing about the request survives it. |
| Referral-link click counts (the count, and the day-scoped fingerprint described above) | This is a new measurement and we have not yet set a fixed retention period for it. Nothing deletes it automatically today; we will publish a period here once we have. |
| Operational logs kept by Google as our hosting provider | Google’s default retention for this project, currently thirty days, after which they are deleted automatically. |
| What is on your own device | Until you clear it. Nothing in that table has an expiry set by us, and clearing your browser data removes all of it — the table above says what you lose if you do. |
At the end of a period the record is deleted. Where something has to be kept for one reason but not another — an order we must keep for tax purposes after an account has been closed, for instance — what remains is the part with a reason behind it, and nothing more.
Over information we hold about you, you have the right to:
Use the contact page for any of these. We reply within one month, and we tell you if a request is complicated enough to need longer. There is no charge. We may ask for enough information to be satisfied you are who you say you are — handing someone’s records to the wrong person is the failure a rights request is most likely to cause.
Some rights have limits. An order record we are required to keep for tax purposes cannot simply be deleted on request, and where that is the position we say so and explain why rather than declining without a reason.
We do not send marketing. There is no newsletter and no campaign, and an email address given with an order or a message is used to deal with that order or that message.
What has changed is that the choice now exists before the thing it governs. If you have an account there is a marketing setting in it. It is off unless you turn it on, nothing is sent through it today, and turning it off again is the same one tick in the same place. We built the switch first on purpose: consent added after the fact is a retrofit over everyone who was already collected from.
Order and account emails are a separate thing and are not covered by that setting. They are the receipts, confirmations and security messages that go with something you did — an order, a password reset, an address check — so there is no switch for them.
We do not make decisions about you by automated means that produce a legal effect or anything similarly significant, and we do not profile anyone. The one automated rule on the site is the abuse counter described above: too many submissions from the same origin within an hour are refused for the rest of that hour. It counts requests, not people, and if it ever stops you doing something you legitimately need to do, tell us through the contact page and we will sort it out.
This site is for people aged 18 or over who are buying research materials for laboratory research use.
The site is not intended for anyone under 18 and we do not knowingly collect information about children. The notice shown on a first visit records that it has been seen on that device; it is an acknowledgement rather than an age check, and we do not claim it is anything more. If you believe we hold information about a child, tell us through the contact page and we will delete it.
The measures below are the ones that actually protect the records, described plainly rather than as a list of adjectives.
No system is completely secure, and we would rather say that than promise otherwise. If something does go wrong and there is a risk to people, we tell the Information Commissioner’s Office within seventy-two hours of becoming aware of it, and we tell the people affected where the risk to them is high.
If you are unhappy with how we have handled your information, tell us first through the contact page. We would rather put something right than have you take it elsewhere unanswered, and a complaint is acknowledged within five working days.
You can also complain to the Information Commissioner’s Office, the UK regulator for data protection, at ico.org.uk. You do not have to come to us first, and complaining to us does not affect your right to go to the ICO.
This is version 1.2, published on 14 September 2026. The version and date at the top of the page always say which wording you are reading.
When we change it, the new version replaces this one here and the date changes with it. If a change materially affects what we do with information we already hold, we say so on the site rather than relying on you to re-read the page. The first section above changes on its own as the site changes, because it is generated from the code.