Oasis Sapphire primary sources — 2026-05-14

Project status in this pass

• Oasis Sapphire’s clearest primary materials in this pass were the official Sapphire docs, especially the overview, concepts, Sapphire vs Ethereum, security, encrypted-events, and call-authentication pages, plus the canonical sapphire-paratime monorepo README.
• No Sapphire-specific standalone whitepaper surfaced in the reviewed official materials.
• The main reason Sapphire matters for the corpus is that it makes confidential EVM execution unusually legible as separate layers: encrypted state, encrypted ingress, authenticated private reads, public-versus-encrypted event handling, and side-channel mitigation.

Primary-source snapshots

1) Sapphire overview page

• URL: https://docs.oasis.io/build/sapphire/
• Key excerpts/signals:
  • Calls Sapphire the official confidential ParaTime for smart-contract development with EVM compatibility.
  • Highlights confidential state, end-to-end encryption, confidential randomness, low fees, and fast finality.
• Why it mattered:
  • This is the cleanest short statement of Sapphire’s intended identity: an Oasis execution environment that preserves EVM familiarity while changing confidentiality guarantees.

2) Concepts page

• URL: https://docs.oasis.io/build/sapphire/develop/concept/
• Key excerpts/signals:
  • Says transactions and calls should be encrypted and signed for maximum security.
  • States that all contract state is encrypted and not accessible to anyone except the contract, which can request its state key from the Oasis key manager while executing in an attested compute node.
  • Explicitly warns that access patterns, gas use, and emitted logs can still leak information.
• Why it mattered:
  • This page is the strongest source for Sapphire’s actual confidentiality boundary and its explicit limits.

3) Sapphire vs Ethereum page

• URL: https://docs.oasis.io/build/sapphire/ethereum/
• Key excerpts/signals:
  • Says Sapphire is generally compatible with Ethereum and the EVM but adds encrypted state, encrypted calls/transactions, private entropy, and onchain signing capabilities.
  • Notes that eth_getStorageAt returns zero for normal storage slots and that unsigned calls have sender zeroed.
  • Explains Sapphire’s instant-finality model and the implications for bridge responsiveness.
• Why it mattered:
  • This page cleanly enumerates the protocol-level semantic differences from a transparent EVM rather than treating Sapphire as Ethereum, but private.

4) Security guidance

• URL: https://docs.oasis.io/build/sapphire/develop/security/
• Key excerpts/signals:
  • Documents simulation attacks where secrets can leak from static-call execution unless contracts enforce a block-delay or similar finality check.
  • Warns about storage-access-pattern leakage and gas-based side channels.
  • Introduces Sapphire.padGas as an execution-gas equalization tool and explains its limits.
• Why it mattered:
  • The security chapter is one of the best reasons to keep Sapphire in the active corpus: it makes the practical leak surfaces of confidential smart contracts explicit instead of hiding them behind the word private.

5) Encrypted events page

• URL: https://docs.oasis.io/build/sapphire/develop/encrypted-events/
• Key excerpts/signals:
  • Shows that Sapphire keeps event topics public for indexing while allowing event payloads to be encrypted.
  • Documents several concrete patterns: direct symmetric-key passing, onchain ECDH-derived keys, and ROFL-oriented onchain key generation.
  • Exposes specific Sapphire cryptographic helpers such as randomBytes, encrypt, and Curve25519 key-derivation functions.
• Why it mattered:
  • This page makes Sapphire’s middle layer clearer: confidentiality is not only about hidden storage, but also about how developers deliberately manage public triggers versus private payloads.

6) Call-authentication page

• URL: https://docs.oasis.io/build/sapphire/develop/authentication/
• Key excerpts/signals:
  • Explains that unauthenticated eth_call requests always arrive with msg.sender == address(0).
  • Documents two authenticated-read paths: SIWE-token-based view calls and EIP-712 signed queries.
  • Shows how contracts can use Sapphire’s auth helpers to release secrets to authenticated readers without requiring every private read to be an onchain transaction.
• Why it mattered:
  • This page makes private-read authorization a first-class protocol surface rather than a secondary app concern.

7) Canonical monorepo README

• URL: https://raw.githubusercontent.com/oasisprotocol/sapphire-paratime/main/README.md
• Key excerpts/signals:
  • Describes Sapphire as the official confidential EVM-compatible ParaTime on Oasis.
  • Makes the implementation surface visible through runtime, contracts, clients, examples, integrations, and docs directories.
  • Shows that Sapphire is a maintained developer platform, not only a marketing page.
• Why it mattered:
  • The repo README is useful because it turns Sapphire from a documentation concept into a concrete open-source runtime and tooling stack.

Working conclusion

Oasis Sapphire is best cataloged as confidential EVM execution infrastructure whose key reusable mechanism is the combination of encrypted state, encrypted ingress, explicit call-authentication semantics, and precompile-level confidentiality utilities. The most important signal from primary docs is that Sapphire also foregrounds the leak surfaces and developer obligations that remain: event/log design, storage-access patterns, simulation attacks, and gas side channels are not incidental footnotes but central parts of the trust model.