Privacy Policy

Status: published. Prepared against the product as built. A version reviewed by counsel, when issued, replaces this one under its own changes section. Version: 2026-11-04 · Effective: 2026-11-04 · Registry slug: privacy Operator: Moretime.ai Inc., a Texas corporation ("we", "us", "OnTheList.Live") · Contact: hi@moretime.ai · Postal address: 5900 Balcones Drive, Suite 100, Austin, TX 78731, United States

1. Who this is for

This policy is for everyone OnTheList.Live holds information about — you, if you:

• visit a public board, the Round Archive, or the marketing pages at / and /scorecard (a visitor);
• apply on / or /scorecard to become a host, whether or not you pay the host access fee there, or are invited by us to host without applying (a host applicant);
• bid, or try to, for a placement on a board, with or without a sponsor account, or open a sponsor account yourself (a sponsor);
• run a board, or belong to an organisation that does (a host);
• report a listing using the "Report a listing" control (a reporter).

It describes the service as built today: where a mechanism is not in the software, this policy does not promise it. Board, round, listing, bid, placement and house entry are used as the Bid Rules use them; a magic link is the 24-hour link Contact and Support describes.

2. Who is responsible

Moretime.ai Inc., a Texas corporation, is the controller of the personal data described here — the company that decides what is collected and why. OnTheList.Live is one of its products. Write to hi@moretime.ai about anything on this page; one mailbox is the whole contact surface, read by the people who run the service. The service is offered from and in the United States, and the data is held there (section 8); it is not directed at people in the European Economic Area or the United Kingdom, and we have appointed no representative and no data protection officer there.

3. The short version

• We hold your email address and what you did with it. We do not sell it, rent it, or share it for anyone else's marketing.
• Payments for placements go through Stripe to the host's own Stripe account; the host access fee — the one-time fee to become a host — goes through Stripe to ours. We never see your card number. Hosts never give us identity documents; Stripe's verification handles that, and Stripe keeps it.
• A raw IP address is kept in a handful of named places, each with a stated life, and nowhere else.
• Payments, bids, refunds and disputes are kept as financial records, with no end date. The evidence that a charge was agreed to — the IP address and device fingerprint recorded at checkout — is blanked after 540 days (about eighteen months). Section 6 has the whole table, including the records that have no time bound.
• Erasure is pseudonymisation of the records that must stay, never deletion of them. We assess each request individually and tell you which records we keep and why. Section 9 says what that means.
• The Round Archive is permanent: the public record of a settled round. It holds no email address, but it keeps each settled listing's name — the business name its sponsor gave, or the page's title, else its address — and destination for ever.
• Google Analytics runs on the two marketing pages and a board's own pages only after you say yes, wherever you are, with Google Signals off; a browser that sends Global Privacy Control and has made no choice is not asked (Cookie Policy, section 4). Nothing else of ours carries analytics. A board counts the visits that arrive from an AI answer engine, by the engine's name alone (section 4).
• The forms on those two pages run a human check by Cloudflare, which receives your IP address and signals from your browser while the form is shown; we keep nothing from it (section 7).
• A click or a scan of a listing reaches the business's website with three tags naming OnTheList.Live, the board and whether it was a scan, so the business's own analytics can count the visit; nothing in them identifies you (section 7).

4. What we hold, and where it comes from

Almost everything below comes from you: a form, a click, a payment. Five things do not. The destination page you point a listing at supplies its title (shown unless you give a business name), description and image. Stripe tells us that a payment happened and what it looked like from its side. The public profile of a social account a host names on its board supplies that account's follower count (section 4.4). We supply an email address when we invite a person to host who has not applied (section 4.2). Your browser supplies an address and a description of itself with every request, and — at checkout, with an application and with a request for a sign-in link — the time zone it is set to; we record those in the places named below and nowhere else. Our pages also read, in your browser, whether it sends a Global Privacy Control signal, to decide whether to ask about analytics (section 13); on a board or a shared placement's page, how the page was opened, so that a reload is not counted again; and, on a board, the address of the page you came from and of the link you opened, to tell whether an AI answer engine or a shared link sent you (sections 4.1 and 4.3). None of these readings is stored or sent to us, except the engine's name and the kind of shared link, with the placement a rank share names; where analytics run, the page you came from and the link you opened also reach Google, trimmed as section 7 describes.

4.1 Visitors

Reading a public board needs no account, and sets no cookie of ours until you make an analytics choice or turn on dark mode. The marketing pages at / and /scorecard and a board's own pages ask about analytics before any analytics cookie is set, and Google Analytics runs only after you say yes; a browser that sends Global Privacy Control and has made no choice is not asked. A choice is recorded in one cookie (Cookie Policy, sections 4 and 5). Their forms also run Cloudflare's human check, which the table below and section 7 describe.

Our application log holds no client address; our error records name the route pattern, not the URL, because several of our URLs are credentials; and a database query that fails is recorded with its values masked — a value shaped like an identifier (a number, a date, a status word, an id) is kept, so a one-word capitalised name can pass; an email address, a name of more than one word, a network address and free text never are.

4.2 Host applicants (/, /scorecard, or our invitation)

An application is one row keyed on your email address; applying twice is the same row. If we invite you to host without your having applied, we make that row ourselves, from the address we typed: it holds your address, the role host, when we made it, the invitation and its status — no answers and no version of this policy. An application holds:

• your email address and your role: host (an application made while the form also offered sponsor, or both, keeps the choice made then until you apply again from the host form);
• your five scorecard answers, an audience-size band, and the total and fit band worked out from them (older rows hold fifteen answers), plus two eligibility answers — hosts only;
• the form you used and the moment you submitted it, which is when you asked us for host access;
• the version of this policy in force when you applied, recorded from version 2026-09-17 on: an application submitted under an earlier version holds none, and applying again records the version in force at that submission;
• a status (new, invited, declined) and when it was set: by a person, by hand, or by our system — which invites you once Stripe confirms a payment of the host access fee, and marks the application declined and cancels an unused setup link if every payment of the fee is refunded before you use it. Applying without paying entitles nobody to a board;
• once we invite you, a one-way hash of the invitation link (the setup link) and its expiry (seven days). The link itself exists only in the email;
• a back-reference to the organisation you go on to create, set only when onboarding completes.

When you press Continue to pay the host access fee — the one-time fee to become a host — we also keep a record of each checkout you start, whether or not you then pay: Stripe's identifier for it, the amount and currency, when you started it and when it expires, and the versions of the Host Terms and the Refund Policy you accepted by ticking the box before paying; once you pay, the amount paid, Stripe's identifier for the payment and when we recorded it; any amount refunded; and, if a refund of it fails at your bank, when that was recorded and the reason code Stripe gave. That record holds no email address — it points to your application — and no card detail. You pay on Stripe's page, which we open with the address you applied with already filled in as the payer's email; there you enter your card and whatever Stripe asks for, and we never receive the card number or the security code. What comes back is Stripe's event records about your checkout, each kept whole for 540 days — the payment, and also a checkout left to expire, a card Stripe declined, a refund or a dispute. They can carry the details section 4.3 lists for a sponsor's payment, and a declined card's decline code.

Your answers are numbers from a fixed set and cannot hold a name, an address or free text. The application also records the time zone your browser reports, so your invitation shows its expiry in your zone; neither record holds an IP address or a browser description.

4.3 Sponsors

At checkout, before you are sent to Stripe, we record:

• the destination you typed, in the four forms we derive from it;
• your email address, and whether you ticked the outbid-alert box;
• that you ticked the finality checkbox and the age affirmation, at what instant, and which version of the Terms you accepted. The two texts are quoted exactly as they appear on the form: I understand bids are final and my rank can change as others bid and I am 18 or older and bidding on my own behalf or for a business I represent;
• your IP address, unhashed, held so that it can be shown to a card network if you later dispute the charge — a hash is worth nothing there — and, on a board whose blocked websites refused a website, compared (hashed under our key for that board, automatically) with the refusals recorded there (section 5);
• a device fingerprint: a one-way hash of your browser's user-agent string and language setting. It is a comparison value, not an identity; two people on the same phone and browser share one;
• the time zone your browser reports, so the emails we send you about this bid show times in your zone;
• whether you reached the board through a link someone shared — only which kind of link (a board share or a rank share), never whose — so the host can see how many paid placements came from sharing;
• Stripe's session identifier and the checkout page's address;
• the bid, the service fee — our fee and the card processing, charged to you on top of the bid — any sales tax Stripe added for the host, and the all-in total; on a board whose host approves each listing first, the identifier of the hold Stripe placed on your card and when it lapses;
• what you wrote and chose on the "Your listing" step, if anything: your business name, your short line, the tags you picked, the instant you affirmed an offer tag, and the logo you added (held as described in section 4.3's table).

At Stripe, on the host's page, you enter your card and whatever Stripe asks for. We never receive the card number or the security code, and we do not prefill your address into Stripe's page. What comes back is Stripe's event record, kept whole: it can carry the name, email address and billing address you gave Stripe, the card brand, its last four digits, expiry month and year and issuing country, an opaque card fingerprint, and a phone number if Stripe asked you for one. On a board whose host collects sales tax, Stripe asks for your billing address to calculate it, so that record carries it.

After a paid bid we hold the payment, the bid, the ledger lines behind it (the bid, our fee, the card processing and any tax), and the listing, which carries your email address as its owner for the round — and on the copy carried into the next round of a reset board.

A first paid bid creates a sponsor account for your address, whether or not you asked for one. It holds your address, a placeholder name (the part before the @) and a profile image address if you ever set one (no page offers it today), and has no password until you set one; we email the address a link to claim it. You can also open a sponsor account yourself at sponsor.onthelist.live, before any bid: it holds the address and the name you type there (an address that already has an account keeps the name it has), and has no password you know until you choose one through the link we email to that address. Spending a link we mailed is the only thing that proves an address is yours — never that somebody typed it.

A sponsor may also have:

4.4 Hosts and their team members

We hold no identity document, date of birth, tax number or bank detail for any host. Stripe collects those on its own pages, under its own privacy policy, and keeps them.

4.5 Reporters

A report holds the reason you chose, the details you wrote (optional), your email address (optional), and your IP address, unhashed. It is recorded and queued for a person; it never takes a listing down by itself, and the answer you see is the same whether or not the listing exists.

5. Why we hold it

We make no automated decision about you with a legal or similarly significant effect. Rank is arithmetic on amounts paid, not a judgement of you. Three automatic actions touch a placement, and each is a contract mechanic stated elsewhere: a payment completing after the round ended is refunded, everything but the card processing, and a held listing is rejected and its card hold released, nothing charged, when its round ends unreviewed (Refund Policy); a listing is suspended when a card dispute on it is coded as fraud — never a placement another sponsor bought after refunds had brought the listing to $0. A person reviews any of them on request (Prohibited Content Policy, section 7).

6. How long

Our retention is written in code, per table, with the clock each rule is measured on; this table states it as the code does. 540 days is the evidence tier — the "evidence period" our other policies refer to: the period within which a card network can raise a dispute, plus margin. 30 days is the operational tier. Several records have no time bound and the table says so ("Kept" or "For ever"): the financial records, listings, accounts and their sign-in records, an open report until a person resolves it, notification preferences, and the Round Archive. Where a personal detail sits on one of those records, section 9 says what a request can reach.

When the law, a court, a regulator or law enforcement requires us to keep a record longer than this table says, we copy the records concerned out by hand before the schedule reaches them and keep the copy for as long as we are required to. The schedule itself has no hold in it; the copy is how we comply.

Why the Round Archive is permanent: it is the public record of a settled round — who held which position at the end, at what bid total — and a later refund or dispute of a payment behind it annotates it rather than rewriting it, so that a result once published never changes. A row holds a listing id, a rank, a bid total, the listing's name (the business name its sponsor gave, or the page's title, else its address) and its display URL — no email address, and an email-shaped string inside a name or URL is blanked before the row is written. Once written, nobody, including us, can edit or delete it. A row can still identify a sponsor who advertised a destination that names them; that is the trade-off of a public record. A request about such a row is assessed individually under section 9 and answered with which records we keep and why: we cannot edit the row, and we do not today offer to hide part of it on the page while leaving it in the record.

7. Who else handles it

Each receives only what its job needs. Where we know where a recipient holds the data, the row says so; the systems we run are all in the United States.

There is no content delivery network (Cloudflare's only part is the human check above), error-reporting vendor, session recording, chat widget or advertising network, and no data broker beyond scrapecreators.com's reading of a public follower count (above); no advertising feature is on anywhere — Google Signals is off (Google, above). Let's Encrypt (or ZeroSSL, the fallback our web server uses if Let's Encrypt is unavailable) issues our TLS certificate and learns our domain name, nothing about you. Our identity library runs inside our own server and sends nothing anywhere.

8. International transfers

We are a US company and the data is held in the United States, in AWS's us-east-1 region. The service is not directed at people in the European Economic Area or the United Kingdom, and we have appointed no representative and no data protection officer there (section 2). If you use the service from there anyway, your data is transferred to and held in the United States, and the rights in section 9 are honoured as that section states.

9. Your rights, and what happens when you use them

Every request goes to hi@moretime.ai, with Privacy in the subject line, and is handled by hand: there is no export button, no deletion button and no self-service erasure. Writing from the address on the record is normally enough to identify you; we may ask for more when money is involved. Requests are free, and we aim to answer within one month. We assess each request individually: where we keep a record, we tell you which one and why. If you are in the EU or the UK, the rights below are the ones those laws give you, and this is how to exercise them.

• Access. We will tell you what we hold about the address you write from, with a copy.
• Correction. A sponsor with an account can change their display name; a host can change their organisation's name, type, bio and social handles in the board editor. Ask us to correct anything else.
• Portability. We will send you your data in a common machine-readable format on request.
• Objection and restriction. Object to any processing based on legitimate interests and we will stop unless we can show a compelling reason; an objection to keeping a host application deletes it. Withdraw consent for outbid alerts or analytics at any time; withdrawal does not affect what came before.
• Erasure — what it means here. Erasure is pseudonymisation: we replace the columns that identify you with a pseudonym, or blank them where a record can stand without them, and leave the record itself standing where it is one of the following. The reason is what each record is, not how it is stored, and our answer names the records we keep and why:
  • a payment, a bid, a refund and a dispute are financial records we must keep, and the evidence that you agreed to a charge is kept for 540 days so a dispute can be answered. Your IP address, device fingerprint and time zone on those rows are blanked when that period ends. Your address stays with the payment record; on request, where no dispute window is open, we replace it with a pseudonym rather than blanking it, because the record must still name a payer, and blank the time zone recorded with it — and the money records themselves stay;
  • a listing you paid for stays on the board for the round you paid for, without your address — unless refunds have brought its total to $0: then it is off the board, and its record stays, without your address;
  • the Round Archive is the public record of a settled round, and nobody can rewrite it. It holds no email address (an email-shaped string in a name or URL is blanked before the row is written), but it keeps each settled listing's name — the business name you gave (for a sole trader, perhaps your own name), or the page's title — and destination address for ever. If those name you, we cannot edit the row, and we do not today offer to hide part of it on the page while leaving it in the record; we tell you so, and which row it is;
  • a notification preference is kept so that an unsubscribe stays an unsubscribe;
  • a refusal by a host's blocked websites stays for its 540 days as the evidence of the refusal, with your email address replaced by a pseudonym.

  An account can be closed on request: its sessions end and the columns that identify you — address, name, image — are replaced with a pseudonym, by hand. A host application is deleted outright. If you paid the host access fee, the record of that payment stays as a financial record, holding no address (section 6), and Stripe's event record of the payment is kept for its 540 days.

• Complain. You can complain to the supervisory authority for the place you live. We would rather you wrote to us first, but you do not have to. Texas residents can also complain to the Texas Attorney General (texasattorneygeneral.gov). We do not sell personal data or use it for targeted advertising, and sell no sensitive data (the California paragraph below).
• Appeal. If we refuse a request, in whole or in part, write again with Appeal in the subject line. The founder reads an appeal and answers within one month — the same target as a first request — saying what was decided and why. An appeal does not stop you complaining to a supervisory authority at any time.
• An authorised agent may make a request for you. We ask for written authority signed by you, which we may verify by writing to the address on the record before we act.
• Global Privacy Control and Do Not Track. A browser that sends Global Privacy Control and has made no choice here is treated as having said no to analytics, automatically and before any Google script loads: it is not asked, and nothing optional loads. A choice you make with Cookie settings, or made before the signal was on, is the one followed (Cookie Policy, section 4). Do Not Track is not read.

California residents. We do not sell personal information, and we do not share it for cross-context behavioural advertising. Google Analytics runs only after you say yes, with Google Signals and advertising personalisation off and sharing with Google's other products off in our property; we use what it records only for aggregate reports of how the site is visited, and how Google itself uses information from sites that use its services is set out in the Cookie Policy, section 6. We have no actual knowledge of selling or sharing the personal information of anyone under 16. You have the rights to know, delete and correct described above, and the right to equal service whether or not you exercise them; the rights above are honoured whether or not a statutory threshold makes them mandatory.

10. Children

OnTheList.Live is for adults who run boards or sponsor listings on them. Nobody under 18 may hold an account, run a board or bid: every sponsor affirms at checkout that they are 18 or older, and every host agrees in the Host Terms, section 2, that they are. Stripe applies its own identity checks to the holder of the Stripe account that receives the money, under Stripe's own requirements; we run no age check of our own. A board aimed at children, or at an audience that is predominantly children, is not permitted; the Prohibited Content Policy carries that rule. We knowingly collect nothing from a child; if you believe one has given us information, write to hi@moretime.ai and we will remove it.

11. Security

• Everything is served over HTTPS. The reverse proxy holds the certificate, and the application accepts connections only from it.
• Passwords are stored as hashes; second-factor secrets for platform staff are stored encrypted.
• Magic links, sponsor sign-in links, invitations and API keys are stored as one-way hashes; the plaintext exists only in the email or the one response that showed it to you. Two tokens are held in clear, on purpose: a password-reset or account-claim link, kept by the identity library for the hour it is valid, and the unsubscribe token, kept so it can be re-mailed — it can only stop one class of mail to an address the holder already knows.
• No card number, security code or bank detail ever reaches our systems.
• Platform staff sign in with a password and a second factor. Access to a host's data is decided by the database's record of your membership on every request, never by anything the browser claims.
• A password reset ends every other session on the account.

12. Email and consent

Transactional email needs no opt-in: bid and placement receipts, refund notices, the notice that your card is held for a host's approval (with its link to cancel) and that a hold was released, listing approved, reinstated, rejected or removed, the notice to a board's Owner and Admins of each payment and card hold on their board, magic links, sign-in and reset links, the claim link for a new sponsor account and the link that activates one you opened yourself, and a host applicant's setup link, which we send once Stripe confirms a payment of the host access fee, or when we invite you ourselves. No email we send names a payable amount.

Outbid alerts are sent only if you ticked the box at checkout. They are optional mail you asked for, and each one invites you to raise a bid, so we treat them as commercial mail: every alert carries an unsubscribe link, a one-click unsubscribe header for your mail app, our name and our postal address. Ticking the box on a later bid turns alerts on for an address that had left the box unticked before; once you have unsubscribed, only the "turn alerts back on" button on the unsubscribe page reinstates them. Leaving the box unticked changes nothing. At most one alert per listing per address per hour. Opening the unsubscribe link asks you to confirm; pressing the button unsubscribes you, so a mail scanner that opens links cannot. Your mail app's own unsubscribe button, where it offers one, acts at once through the standard one-click header — that is you pressing a button, not a scanner following a link. A hard bounce, or your reporting one of our emails as spam, also switches alerts off for that address.

We send no newsletter and no marketing email, and pass your address to nobody for theirs.

13. Cookies and analytics

The application sets only strictly necessary cookies — a session cookie once you sign in, the otl-consent cookie that remembers your analytics choice once you make one, and the otl-theme cookie that remembers dark mode once you choose it (it holds only the word dark). /, /scorecard and a board's own pages load Google Analytics only after you say yes, wherever you are, in a plain choice with an equal "no"; declining loads nothing, Google Signals is off, and a browser that sends Global Privacy Control and has made no choice is not asked. No checkout, sponsor, dashboard or admin page loads any analytics or sends anything to Google. The forms on / and /scorecard also run Cloudflare's human check (section 7): it is part of the form, not an optional feature, so it runs whatever you choose about analytics. The Cookie Policy lists every cookie, says where each is set and where your browser sends it, says what the human check keeps in your browser, and explains how to change your choice.

14. Changes to this policy

The version string at the top of this page tells one version from another. Each checkout records the version of the Terms it accepted; a host application records the version of this policy in force when it was submitted, from version 2026-09-17 on (section 4.2); a host access checkout records the versions of the Host Terms and the Refund Policy it accepted. If what we collect, or why, changes, the version goes up, and a change that materially affects people we hold data about is announced by email, not only by editing this page.

15. Contact

hi@moretime.ai, for every question, request, objection and complaint on this page. It is read by the people who run OnTheList.Live and answered by hand. You may send us any notice by email to hi@moretime.ai; a notice the law requires to be served in writing goes to the postal address in the header.