What we guarantee

1. The target is fixed before you start

you can check

When you open a session, the server draws the target and computes a commitment: the SHA-256 of the target's identifier, a 32-byte random value and the session's identifier. The commitment is under “Verify this session”: note it, or copy its first eight characters onto your sheet. After the reveal, the random value is in the reveal data and you can recompute the commitment. If it matches, the target was fixed when you opened the session.

2. The image is fixed too

you can check, for sessions opened since 7 October 2026, 01:42 (Rome time)

The commitment fixes an identifier, not a picture. Since 7 October 2026, the SHA-256 of every image in the pool is recorded before any session can draw it, and anchored in the Bitcoin blockchain with the next batch. After the reveal you can save the five images and check each one against its anchored hash; the verifier also says whether your session is covered, that is, whether the five hashes were anchored no later than your commitment. For sessions opened before that time, which image the identifier names is our word.

3. Your impressions are fixed before you see any candidate

enforced by us, then anchored

You seal the session before any candidate is sent to you: the server refuses to show candidates for a session that is not sealed. Sealing stores a hash of each photograph, as stored after its metadata are removed, and a hash of any text you typed, and those hashes are anchored. A sealed session cannot be edited. The fields of the structured protocol are frozen by the database but not hashed.

4. The five candidates look the same

partly you can check

Every image is stored at exactly the same size, 1 MiB, which you can see in what your browser downloads. The five are shown in the same frame and load together, or none is shown; nothing in how they are served depends on which one is the target. For sessions opened after a change made on 1 October 2026, the order they are shown in is derived from the session's random value and recorded, and after the reveal you can recompute it; the reveal data say which kind your session is. Earlier sessions used an order only we can recompute.

5. You rank without knowing the answer

enforced by us, then anchored

The target is withheld until your ranking is locked. A locked ranking cannot be changed, and it is anchored with the time it was locked.

6. Every ranking you lock counts

enforced by us

Once seven days have passed since you locked a ranking, if you have not revealed it, the site reveals it for you at its next scheduled run, and it counts like any other. A session abandoned before the ranking is counted as abandoned, not dropped. Every session you open leaves an anchored commitment.

7. Nothing is rewritten afterwards

you can check, for your own session

Commitments, seals, locked rankings, image hashes, declared exclusions and every check of the stopping rule are written to tables whose triggers refuse edits and deletions. The one exception is the purge of guest sessions after a day, which removes a guest session's link to its commitment and keeps the commitment. That binds the application, not us: we run the database. What binds us is the anchoring. On a schedule set for every hour, everything new is gathered into one hash, chained to the batch before, and stamped in the Bitcoin blockchain through OpenTimestamps within a few hours. Once a record's batch is in a Bitcoin block, changing the record would break its proof. You can check this for your own session. Other sessions' records, and the checks of the stopping rule, can be checked only by whoever holds them: the full record is not public.

8. Exclusions are declared, never chosen by outcome

enforced by us

A session can be left out of the analysis only by a declaration, under a reason fixed in advance that concerns where the session came from, never how it went. Each declaration records its date, and the analysis shows whether it came before the session was sealed. Each declaration names the section and commit of the preregistration notes that make it, and those notes are public on the preregistration page. Guest sessions are never data.

9. The rules come before the data they govern

partly you can check

The analysis decisions taken so far, the stopping rule and every change to them are in our preregistration notes at /preregistration, with the hash and OpenTimestamps proof of every version; only the current text is published. The stopping rule and each change to it apply from an instant stated in their text, no earlier than the commit that added it. Each proof shows that a version existed by its Bitcoin block, some hours after it reached us; that it was committed before the instant it states rests on git dates, which we control. Sessions opened before the stopping rule was declared stay exploratory. The notes are not yet lodged with a registry, and the confirmatory hypothesis is not yet declared.

10. The operator's hand shows where it matters

• you can check

  Closures. If the operator erases an account whose study has data counted, the closure is published automatically, with the date, the reason, the phase, the number of data and, if the study reached a checkpoint, the last Bayes factor recorded, at /api/v1/stopping/operator-closures.

• enforced by us

  Looks at results. Every look at results through the research panel is recorded with its date and reason. The log is not public, and it does not cover direct access to the database.

11. Your data

enforced by us

No email address is ever asked for, and your IP address is not stored in clear. You can delete your account from your account page: we delete your nick, your credentials and every sheet you photographed, and your nick can never be registered again. Our database host keeps a rolling six-hour history of the database for recovery; after that, none of it can be brought back. Your sessions stay, with no name on them: ranks, times, targets, the pre-session answers, any text you typed, and the hashes and capture times of the photographs. They stay linked to one another by an identifier that carries no name. Typed text cannot be removed after the seal; if that matters to you, put everything on paper. You can download your account and everything in its sessions, as one file, from your account page. Our host, Vercel, keeps logs of requests with your address for a period it decides, and Cloudflare Turnstile, on the pages that ask you to prove you are human, receives your address and signals from your browser. The original of a photograph, metadata included, is deleted at the seal, or at the latest by the second scheduled sweep after the session is sealed or ends.

What we cannot guarantee

• The server during your session. The anchors prove that nothing was changed afterwards. They cannot prove that the server behaved honestly while your session ran. That rests on the design described here and on code you cannot read.
• The first hours. A record waits for the next scheduled batch, then a few hours for Bitcoin; inside that window only the database protects it. Until 5 October 2026 the scheduled runs that build batches started between 48 minutes and 8 hours 21 minutes apart. The verifier prints the actual gap for each record of your session.
• The early record. Records written before the first batch, on 3 October 2026, are proven from that batch, not from when they were written. Versions of the preregistration notes from before 2 October 2026, 23:41, are proven from then.
• What was on your screen during the ranking. The image check fixes the bytes served after their batch. Files you save during the ranking would catch a substitution; files saved after the reveal would not.
• The code is not public. You can check your own session's records, with a public verifier that shares no code with the site; you cannot read the software that produced them.
• That this kind of target suits remote viewing. A result at chance cannot tell “no effect” from “wrong kind of target”.

How to check, step by step

You need Node.js 18 or later and a terminal. When you open a session, note the commitment under “Verify this session”.

Your session

1. After the reveal, open /api/v1/sessions/<session id>/reveal in the same browser, where you are signed in, and save the page as reveal.json. Only you can fetch it.
2. On the reveal screen, under “Save the five images”, save A.jpg to E.jpg into the same folder.

3. Download the verifier:

   curl -o verify-anchor.mjs https://www.bearemoteviewer.com/verify-anchor.mjs

4. Run it. It recomputes the commitment and the order the five were shown in, checks each record of your session and its path to its batch, the chain of batches since the first, the Bitcoin block, and each image against the five anchored hashes:

   node verify-anchor.mjs session reveal.json --image A.jpg --image B.jpg --image C.jpg --image D.jpg --image E.jpg --batches https://www.bearemoteviewer.com/api/v1/anchor/batches

   Exit code 0: everything checked, Bitcoin included. 3: valid so far, but a proof is not yet in a Bitcoin block; save reveal.json again in a few hours and rerun. 1: something did not verify; read the FAIL lines. A FAIL ending in “could not be checked: fetch failed” means a block explorer did not answer: run it again.

5. Compare the commitment with the one you noted at the start:

   node -e "console.log(require('./reveal.json').commitment.commit)"

6. To recompute the commitment without our verifier, with Node's own SHA-256:

   node -e "const c=require('crypto'),r=require('./reveal.json').commitment,u=s=>Buffer.from(s.replace(/-/g,''),'hex');const h=c.createHash('sha256').update(u(r.targetId)).update(Buffer.from(r.nonce,'hex')).update(u(r.sessionId)).digest('hex');console.log(h===r.commit?'commit OK':'commit MISMATCH')"

7. The same for the order the five were shown in, if pack.orderScheme in reveal.json is 2:

   node -e "const c=require('crypto'),r=require('./reveal.json'),n=Buffer.from(r.commitment.nonce,'hex'),u=s=>Buffer.from(s.replace(/-/g,''),'hex'),k=id=>c.createHash('sha256').update(n).update('order').update(u(id)).digest();const o=[...r.pack.members].sort((a,b)=>Buffer.compare(k(a),k(b)));console.log(o.join()===r.pack.presented.join()?'order OK':'order MISMATCH')"

8. To trust no block explorer, take the block headers from your own Bitcoin node and pass them with --headers headers.json; the format is in the verifier's first lines.

A version of the preregistration notes

Only the current version's text is published; for earlier versions there is the hash and the proof.

1. Download the current text:

   curl -o preregistration.md https://www.bearemoteviewer.com/api/v1/preregistration/document

2. Compute its SHA-256 and compare it with the hash marked “this one” on /preregistration:

   sha256sum preregistration.md

3. Download the proof for that hash, with the hash in place of <sha256>:

   curl -o preregistration.ots https://www.bearemoteviewer.com/api/v1/preregistration/stamps/<sha256>.ots

4. Verify it, or use ots verify from the OpenTimestamps client:

   node verify-anchor.mjs file preregistration.md preregistration.ots

On Windows. In Windows PowerShell type curl.exe wherever these steps say curl: plain curl is a different command there. For the hash, use (Get-FileHash preregistration.md).Hash.ToLower() instead of sha256sum. The node commands work as written in PowerShell and in bash.