The blockchain layer
Sciencera runs on the Solana blockchain. This page explains why, what's there, and what it means for you.
Why Solana
We picked Solana for four practical reasons:
- Fast. A confirmed transaction in roughly half a second. Important for a network where reviewers, authors, and labs all sign things in real-time workflows.
- Cheap. Transaction fees are typically a small fraction of a cent. Recording fingerprints and status changes shouldn't cost meaningfully more than not.
- Programmable. We can write our own logic — proposal lifecycles, credential issuance — instead of forcing it into a generic NFT or token model.
- Active developer ecosystem. The tools, the wallets, the explorers, and the indexers are all production-grade.
We don't bridge to other chains. We don't fork. The whole platform is end-to-end on Solana.
What's on chain (and what isn't)
Sciencera's blockchain footprint is small and intentional:
| On chain | Off chain |
|---|---|
| Cryptographic fingerprints (32-byte numbers) | Full proposal content |
| Status records (submitted / approved / etc.) | Reviewer comments |
| Reviewer authority records | Credential metadata details |
| Credential issuance records | Lab reports & attachments |
| Wallet addresses (already public) | Personal information |
The blockchain is a public receipt log. It proves things happened, by whom, and when. The actual readable content lives in access-controlled off-chain storage.
The two programs
A "program" on Solana is what other ecosystems call a smart contract. Sciencera ships two of them.
Research Registry
Anchors proposals and their lifecycle.
It records:
- Each proposal's fingerprint, content pointer, vertical, development stage, and milestone count
- The current status (submitted / under review / revision / approved / rejected)
- A revision counter (so resubmissions don't quietly overwrite history)
- Who can act as a reviewer, and which proposals they're assigned to
- Status transitions, each tied to the reviewer who made them and a fingerprint of the review content
For more detail, see How proposals stay tamperproof.
Reputation Credential
Issues non-transferable credentials.
It records:
- Each credential bound to a wallet (the recipient)
- Who can issue which kinds of credentials (Academy, reviewer contribution, milestone participation, lab verified)
- Whether each credential has been revoked, when, and by whom
- An optional pointer to a token-2022 mirror mint for wallet display
The "non-transferable" part is by construction: there's no transfer instruction. A credential cannot be sold, traded, or moved. It's bound to the wallet it was issued to.
For more detail, see How reputation works.
Authority model
There is no single key that controls Sciencera. Authority is split:
| Role | What they can do |
|---|---|
| Admin | Pause / unpause the program. Link approved proposals to milestone funding or IP modules (when those ship). Set the optional credential mirror mint. Revoke any credential. |
| Reviewer manager | Add reviewers. Deactivate reviewers. Cannot pause. |
| Issuer manager | Add credential issuers. Deactivate issuers. Cannot pause. |
| Reviewer (with assign permission) | Assign themselves or peers to specific proposals. |
| Assigned reviewer | Move a proposal's status forward. |
| Issuer (with type permission) | Issue credentials of types they're permitted for. |
| Issuer (with revoke permission) | Revoke their own past issuances. |
On mainnet, every role is held by a Squads multisig — a wallet that requires multiple signers to act. No single person can do anything dangerous.
Forward-compatibility
We don't ship every module on day one, but we plan for them. Two big future modules are referenced from the proposal record by reserved pointer slots:
linked_milestone_escrow— for stablecoin milestone funding (a future module)linked_ip_asset— for IP-NFTs and licensing (a future module)
These are empty today and can be filled in later by the admin once a proposal is approved. The slots existing means we don't need to break the proposal data model when these modules ship.
Every account on chain also carries a version field plus a reserved buffer of bytes. This means we can evolve the data model gracefully without orphaning the records that are already there.
Hashes
Sciencera uses SHA-256 for every fingerprint on chain. 32 bytes. Computed identically by your browser and by the on-chain programs. A zero hash (all zeros) is rejected — every fingerprint must be the result of actually hashing something.
This matters because the verifier path is binary:
- Fetch the off-chain content.
- Compute its SHA-256 in your browser.
- Compare with the on-chain fingerprint.
- Equal = original. Different = tampered.
There is no "maybe it was the same."
Events
Every state-changing action emits a structured event. Indexers subscribe to these to build dashboards, send alerts, or build search indexes. The notable events:
Research Registry
| Event | When it fires |
|---|---|
ProposalSubmitted | New proposal recorded |
ProposalStatusChanged | Status moves forward |
ProposalRevisionSubmitted | Author resubmits after revision request |
ReviewerAdded / ReviewerDeactivated | Reviewer registry changes |
ReviewerAssigned | Reviewer bound to a proposal |
ProposalLinked | Approved proposal connected to a future module |
PausedChanged | Program paused or unpaused |
Reputation Credential
| Event | When it fires |
|---|---|
CredentialIssued | New credential bound to a wallet |
CredentialRevoked | Credential marked revoked |
IssuerAdded / IssuerDeactivated | Issuer registry changes |
CredentialExternalMintSet | Optional token-2022 mirror mint attached |
PausedChanged | Program paused or unpaused |
What's deployed today
The two programs are written, tested, and ready. Local builds run cleanly when the dev environment is set up correctly. Devnet and mainnet deploys are the next milestone.
Every program ID we've used so far (in development) is a placeholder. Before mainnet deployment, fresh keypairs are generated to break provenance from dev/test.
Before mainnet
A short checklist that has to be true before mainnet goes live:
- Both programs audited by a third party
- Fresh program keypairs generated (separate from devnet)
- All authority roles handed to Squads multisigs
- Sufficient SOL balance for program rent
- Off-chain storage infrastructure live (pinning provider chosen, indexer running)
- App configured with mainnet program IDs
- Monitoring dashboards subscribed to events
- Rollback plan documented
Where to go next
- How proposals stay tamperproof — the proposal lifecycle in detail
- How reputation works — credential issuance & revocation
- How the network is run — multisig, monitoring, incident response
- Compliance — the regulatory framing