How the network is run
Everything that keeps Sciencera honest, accountable, and recoverable when things go wrong. This page is for anyone asking: who's in charge, and what stops them from going rogue?
Authority is split, by design
There is no single key that controls Sciencera. Authority is divided among separate roles, and on the production blockchain (mainnet) each role is held by a multisig — a wallet that requires multiple signers to act.
The two on-chain programs and their roles
Research Registry (proposals)
| Role | What they can do |
|---|---|
| Admin | Pause / unpause the program. Link an approved proposal to milestone funding or IP asset (when those modules ship). |
| Reviewer manager | Add new reviewers. Deactivate reviewers. Cannot pause the program. |
| Reviewer (with assign permission) | Assign themselves or peers to specific proposals. |
| Assigned reviewer | Move a proposal's status forward (revision / approved / rejected). |
| Proposal author | Resubmit a revision after a reviewer requests one. |
Reputation Credential (credentials & reputation)
| Role | What they can do |
|---|---|
| Admin | Pause / unpause the program. Revoke any credential. Set the optional Token-2022 mirror mint. |
| Issuer manager | Add new issuers. Deactivate issuers. Cannot pause the program. |
| Issuer (with the right type permission) | Issue credentials of types they're permitted for (Academy, reviewer contribution, milestone participation, lab verified). |
| Issuer (with revoke permission) | Revoke credentials they originally issued. |
Why the split matters
Adding a reviewer is a routine, frequent action. Pausing the entire program is a rare, drastic action. Splitting these into different roles means a routine action doesn't pull in the keys that protect against catastrophes.
The reviewer manager multisig can be 2-of-4 reviewers for fast turnaround. The admin multisig can be 3-of-5 with at least one cold-storage signer for incident response. Each role can be sized independently to match how often it acts and how dangerous a mistake would be.
What happens in an incident
Both blockchain programs have a global pause. An admin can flip it instantly to halt every write — no submissions, no status changes, no credential issuances — without affecting the data already recorded.
This is the equivalent of a circuit breaker. It exists for situations like:
- A bug that lets unauthorized signers do things they shouldn't
- A compromised reviewer multisig
- A regulatory order requiring a freeze
- An off-chain coordination failure that needs time to resolve
When the issue is fixed, the admin unpauses. Existing data is unaffected — only writes were blocked.
What stays public, what stays private
| Public on chain | Private off chain |
|---|---|
| Wallet addresses (already public) | Names, affiliations, ORCID details |
| Proposal fingerprints (32-byte numbers) | Full proposal bodies |
| Status transitions (submitted → approved, etc.) | Reviewer comments and notes |
| Credential records (you have a credential, who issued it, when) | Credential metadata details |
| Issuer authority records | Lab reports & attachments |
The on-chain layer is a public receipt log. Anyone can read it. The off-chain layer is access-controlled storage. The blockchain proves a commitment exists; the off-chain layer decides who can read it.
Monitoring
Every state-changing action emits an event — a structured record indexers can subscribe to. The events that matter most for operational monitoring:
| Event | Why we watch it |
|---|---|
PausedChanged | Critical alert — the program was paused or unpaused |
ProposalLinked | A milestone or IP module was attached to an approved proposal |
CredentialRevoked | A credential was revoked — the subject and the credential type are noted |
ReviewerDeactivated / IssuerDeactivated | Access control changed |
Subscribers can route these to dashboards, on-call alerts, or audit logs depending on their setup. The events themselves are immutable once recorded.
Upgrades and rollbacks
The blockchain programs are upgradable by their upgrade authority — but only by that authority. On mainnet, the upgrade authority is a multisig.
If a deployment goes wrong, the team can redeploy a previous known-good version under the same program ID. Existing data persists across upgrades because every account has a built-in version field designed for migration.
If a bug in the new version breaks something fundamental, the path back is documented. There is no scenario where bad code "wins" because the rollback is a multisig proposal away.
What we do NOT do
- No silent kill switches. Every authority action emits a public event.
- No back doors for the operator. The operator (the company running Sciencera) does not have keys that override user actions or rewrite history.
- No hidden custody. No funds are held by the platform today. Future milestone escrow holds funds in dedicated programs with their own audited code.
- No off-chain authority that overrides on-chain state. If the blockchain says a credential exists, the credential exists. No middleware can pretend otherwise.
Where the keys live
On mainnet, every authority key is a Squads multisig. The recommended structure is documented internally and adjusted as the network grows. The principles:
- Upgrade authority and admin can share a multisig (kept simple for incident response)
- Reviewer manager is its own multisig (more frequent, lower danger)
- Each issuer multisig is sized to the team that needs it (Academy, reviewer council, lab verification council)
- Every multisig has at least one cold-storage signer
Audit posture
- Soft audit, available always. The blockchain is public. Anyone can verify fingerprints, cross-check registries, and trace authority actions.
- Hard audit (SOC 2, ISO 27001, equivalent) is a future operator decision. Individual projects that require certified audits bring their own auditor and use the on-chain evidence as input.
- Pre-mainnet audit. Each blockchain program will be audited by a third party before mainnet deployment.
Where to go next
- Compliance — the regulatory side
- The blockchain layer — the on-chain authority model in detail
- How proposals stay tamperproof — the proposal lifecycle
- How reputation works — credential issuance & revocation