How proposals stay tamperproof

The Research Registry is the on-chain program that makes Sciencera's proposal lifecycle tamperproof. This page explains the lifecycle, who can do what at each step, and why it's structured this way.

What "tamperproof" actually means

The blockchain doesn't store your proposal. It stores a cryptographic fingerprint of your proposal — a 32-byte number derived from the content. Two pieces of identical content produce identical fingerprints. Even a single character change produces a completely different fingerprint.

What this gives you:

• Anyone can fetch your proposal's full content and re-fingerprint it in their browser.
• If their fingerprint matches the on-chain one, the content is authentic.
• If not, the content has been changed since submission. Tampering is detectable.

This is why drafts stay off chain. The blockchain only commits to things you've explicitly submitted — it has no concept of "draft."

The proposal lifecycle

A proposal moves through a small number of states. Transitions are enforced on chain — only valid moves are accepted.

                  submit_proposal
                        │
                        ▼
                  ┌──Submitted──┐
                  │             │
            assign_reviewer     │
                  │             │
                  ▼             │
            UnderReview ◄───────┘
              │   │   │
            update_status (by assigned reviewer)
              │   │   │
              ▼   ▼   ▼
        Revision  Approved  Rejected
              │
        resubmit_revision (by author)
              │
              ▼
            Submitted

The states:

Notice there is no Draft state. Drafts live in your browser, not on chain.

Who can do what

Each transition has a single permitted actor:

Every transition is signed. Every signature is verified on chain. There is no path where the app or operator can move a status without the right authority.

What's stored for each proposal

The on-chain record for a proposal includes:

• Author wallet address — who submitted it
• Proposal ID — a 8-byte identifier chosen at submission
• Title — up to 96 bytes
• Content URI — pointer to the full content (IPFS / Arweave / HTTPS)
• Vertical — one of the six (human health, vet, agriculture, etc.)
• Development stage — hypothesis through field trial
• Status — current state (submitted, under review, etc.)
• Revision counter — bumps every time the author resubmits
• Reviewer count — how many reviewers are assigned
• Proof hash — fingerprint of the structured proposal payload
• Milestones hash — fingerprint of the milestones list
• Tags hash — fingerprint of the tags list
• Funding target — in USD cents
• Milestone count — how many milestones the proposal has
• Timestamps — created, updated, submitted, last reviewed
• Last action — who made the most recent status change, with a fingerprint of the review content
• Optional pointers — to milestone escrow and IP asset (when those modules ship)

The last items keep the proposal forward-compatible. We can attach milestone funding and IP asset records to a proposal later without breaking what's already stored.

Submitting a proposal — what your wallet signs

When you click Submit on the wizard, your wallet signs a transaction containing:

• The fingerprint of your structured proposal payload
• The content URI where the full body lives
• The vertical and development stage
• The fingerprints of milestones and tags
• The funding target and milestone count
• Your wallet address (as the author)

The on-chain program validates each piece:

• Title and content URI within byte limits
• Proof hash is non-zero (you must have actually fingerprinted something)
• Funding target is non-zero
• If milestones exist, the milestones hash must be non-zero too
• The proposal account doesn't already exist (collision check)

If everything checks out, the program creates a new on-chain account for the proposal at status Submitted. The proposal is now in the directory. Reviewers can find it.

Status transitions

Each update_status call by an assigned reviewer:

1. Verifies the reviewer is assigned to this specific proposal
2. Verifies the requested transition is valid (e.g., you can't go from Approved back to Submitted)
3. Requires a non-zero review hash — a fingerprint of the review content
4. Records the new status, the reviewer's wallet, the review hash, and the timestamp
5. Emits a ProposalStatusChanged event

Reviews can't be status-only. The reviewer must commit to specific review content via its fingerprint. That fingerprint is on chain forever, alongside the wallet that signed it.

Revisions

A proposal in Revision status means the reviewer has requested changes. Only the author can resubmit. The resubmit_revision instruction:

• Verifies the signer is the proposal's author
• Verifies the proposal is currently in Revision
• Updates the fields the author chose to change
• Bumps the revision counter
• Records a fresh proof hash for the updated content
• Moves the status back to Submitted

Each revision round has its own fingerprint. The history is preserved through the on-chain event stream — ProposalRevisionSubmitted events for every round.

Reviewer registry

Reviewers are registered globally before they can be assigned to specific proposals. Adding a reviewer is a separate authority action from assigning them — see The blockchain layer for the full table.

Each reviewer record stores:

• The reviewer's wallet
• Who added them and when
• Role flags (review / assign / admin override)
• Whether they're currently active

Deactivating a reviewer doesn't revoke their past actions — only future ones. Existing assignments remain in the record but new actions get blocked at the time of attempt.

What's enforced, ever

The Research Registry enforces these without exception:

• Drafts cannot be created on chain. There is no Draft state.
• Status transitions follow the strict graph above. No skipping, no reversing.
• Only the author can resubmit revisions.
• Only assigned reviewers can move statuses forward.
• Only the admin can link approved proposals to milestone or IP modules.
• A reviewer must be active to act. Deactivation is immediate.
• All proposal accounts have version + reserved fields for safe future migrations.

These aren't conventions. They're checked in every transaction.

Where to go next

• The blockchain layer — the broader on-chain authority model
• How reputation works — the credential program
• Where your data lives — on chain, off chain, browser
• Compliance — regulator framing for the proposal lifecycle