Start here
A work should outlive the website that introduced it
Stratus carries verification into the browser—the place people already experience the work—without pretending one website is permanent.
Most digital art systems collapse four different things into one: the token, the files, the website that displays them, and the rules that control them. Stratus pulls those apart.
Ownership
Who holds the token or collection record.
Presentation
Which exact edition of the work should open.
Content
The HTML, code, images, sound, models, and data.
Verification
How a viewer proves that every resolved byte matches.
We already consume this art in browsers.
Putting assets on-chain but leaving the browser wrapper mutable stops the guarantee one step before the collector. A host can change how files are fetched, assembled, interpreted, or explained. If the wrapper is not verified, “on-chain” does not tell you what actually ran.
Stratus commits to the verifier and its inputs too. Anyone can recover the published code, open it with an open-source host, and run the same checks without trusting the launchpad that first displayed it.
Double-clicking a file is still running code. An operating-system image viewer invokes a decoder, graphics stack, and display pipeline just as a browser does. Browser engines are widely deployed and largely open source. The durable part is the committed format and reproducible verification path—not whether the window has an address bar.
About this guide. It explains the architecture in this repository. A feature is only a live-network fact when Stratus shows the exact network, contract, revision, and current receipt.
Ethereum + Tezos
One promise, two native paths
Ethereum and Tezos use different contract machinery, but both can commit to the same portable identity and let a viewer verify the same creative work.
You do not need to choose a “winning” chain to understand the system. Begin with what stays the same, then open the differences only when they matter to your release.
One SHA-256 identity can be anchored by either native contract system.
Contract-first composition
- Collectible standard
- ERC-721 / ERC-1155
- Address shape
0x…- Contract lane
- Solidity on the EVM
- Native storage
- Immutable bytecode carriers and registries
- Authority style
- Exact signed actions, capabilities, and quorum
Best mental model: small contracts compose into an inspectable graph.
Native records + open carriers
- Collectible standard
- FA2
- Address shape
KT1… / tz…- Contract lane
- Michelson, built here with SmartPy
- Native storage
- Stratus records with an OnchFS-compatible carrier
- Authority style
- Native proposals and separated access roles
Best mental model: native Tezos objects certify the same portable graph.
What both paths promise
- ✓ Keep conventional token metadata available.
- ✓ Bind presentation to an exact digest and revision.
- ✓ Verify decoded files before the work executes.
- ✓ Keep chain-specific location out of the portable content identity.
Open the technical differences
Ethereum: Stratus uses EVM registries for objects, viewers, links, seeds, portable anchors, and other composable capabilities. Conventional tokenURI remains the compatibility door.
Tezos: the current lane uses append-only content records, FA2-compatible collectibles, native anchors, graph certificates, and a shared OnchFS-compatible physical carrier. A viewer still rechecks the exact bytes.
How a work opens
From a token to verified pixels
The viewer resolves a committed manifest, retrieves declared resources, verifies their decoded bytes, and only then runs the work in an isolated frame.
Opening a Stratus work is a proof pipeline, not a blind link in an iframe.
- 01
Find the active presentation
Read the collection or token pointer and its exact revision.
- 02
Verify the manifest
Canonicalize the description and match its committed digest.
- 03
Resolve declared resources
Load only the HTML, CSS, code, media, fonts, and data the manifest names.
- 04
Check decoded bytes
Decompress when needed, enforce limits, then verify length and digest.
- 05
Mount an isolated viewer
Give the artwork the completed verified graph—without a wallet or raw network access.
The chain can prove the stored bytes while the website silently changes resolution, composition, or presentation logic.
A different host may deliver the package, but it cannot substitute verifier logic or content without creating a visible mismatch.
What each file actually does
HTMLStructureThe rooms and labels.
CSSPresentationThe visual language and motion.
JS / WASMBehaviorThe logic, simulation, or instrument.
AssetsMaterialImages, audio, fonts, models, and data.
This also creates better storage protocols. The same portable wrapper that opens art can define how chunks are read, decompressed, joined, verified, cached, and mirrored. Storage becomes a reproducible method—not merely a contract containing links.
Support the wrapper, not every artwork’s internals.
Today each marketplace redesigns the last mile, so the same work can be checked well, badly, or not at all depending on where it opens. The token-bound manifest organizes the resources and pins the viewer logic. A compatible marketplace can open the conventionalanimation_urlpresentation while the wrapper handles contract reads, storage routes, decompression, assembly, integrity, and the proof summary. The marketplace keeps its own experience without becoming the artwork's trust authority.
Portable identity
The art has an identity before it has a location
A portable root identifies exact content. Chain-specific anchors say where that identity was recorded without changing what the work is.
Think of a portable root as the work’s fingerprint. An anchor is a signed page in a particular chain’s notebook saying, “this fingerprint is recorded here.”
same bytes · same root“Is this the same work?”
The portable root changes when the canonical content changes.
“Where was it committed?”
The anchor carries network, registry, revision, and source information.
Storage + mirrors
Permanent does not have to mean one storage religion
Creators can choose on-chain storage, content networks, or verified mirrors. Collectors get a clear source trail and the same byte-integrity check.
Storage is a risk profile, not a moral ranking. Stratus makes the source visible and preserves integrity across more than one delivery path.
Shown when this proof actually resolved that source.
The honest answer when Tezos, IPFS, Ordinals, or another carrier is absent.
Smart contracts
Contracts should make fewer promises—and keep them
Use contracts for durable commitments, authority boundaries, and transparent state. Do not make one contract decide every cultural or product choice forever.
A good contract is a narrow public promise. It should be understandable, independently inspectable, and difficult for any one operator to quietly rewrite.
- Exact content and revision commitments
- Ownership and transferable rights
- Authority roles, thresholds, and limits
- Transparent state transitions
- Portable anchors and provenance receipts
- Choose one permanent marketplace
- Turn every preference into protocol law
- Call a trusted observation “trustless”
- Hide upgrade or recovery authority
- Decide culture on behalf of every artist
How authority differs between the two chains
Ethereum / EVM: the authority lane can use chain-bound EIP-712 signatures, a two-thirds governor threshold, exact capabilities, limited automation, and a stable manager proxy. Permanent art and object data do not sit behind that upgrade proxy.
Tezos: the critical manager is immutable. Native proposals carry exact operation lambdas; access roles and signature authority are separate so an automation key cannot inherit arbitrary administration.
The ethos
Build trustless choices, not compulsory beliefs
Decentralized recoverability is the non-negotiable foundation. Beyond that, Stratus should reveal tradeoffs and let artists, creators, and collectors decide.
Crypto culture often treats one preferred architecture as a character test. Stratus should do something more useful: make the system legible enough for people to choose with informed consent.
Decentralize the guarantee.
Do not centralize the values.
Recoverability before rhetoric
A collector needs a practical route to the committed work, not a slogan attached to a fragile URL.
Declared trust before fake trustlessness
Human review, RPCs, gateways, and councils can be useful. Name them and bound them.
Choice before doctrine
Artists can choose permanence, upgrade paths, markets, licenses, and collaboration models. Collectors can choose what they accept.
Interoperability before capture
Conventional metadata stays available. Richer Stratus behavior should add verification, not require every platform to adopt a custom field.
Exit before loyalty
No launchpad, indexer, or viewer should need to remain benevolent forever for the work to survive.
Freedom includes refusal
A creator or collector may reject the reference browser path. The commitments should remain checkable in another open-source host.
Proof language
Say exactly what is known
A source label, a verified digest, an RPC observation, and a native consensus proof are different claims. The interface should never blur them.
Trust becomes manageable when every claim has a precise label. These labels should appear near the collector’s decision, with deeper receipts available when wanted.
Declared source
The manifest names a carrier or location. This is a claim to verify.
Bytes verified
Retrieved, decoded bytes match the committed length and digest.
Registry-bound
The bytes and revision match the exact contract presentation being inspected.
Trusted RPC observation
A client observed native state at one pinned block through a named RPC. Useful, but not a consensus proof.
Native proof
The verifier checked the source chain’s own consensus evidence for the claim.
Attested proof
Named signers vouched for a bound receipt. The threshold and expiry are part of the claim.
Never promote a weaker label because the interface needs a green badge. “Not declared for this proof” is a complete, useful answer.
Implementation status is also a proof boundary
A clean build proves that source can compile. Local contract tests prove the covered local behavior. A testnet receipt proves one network operation. None of those alone proves a mainnet deployment, independent audit, marketplace render, or permanent availability. The viewer should state the strongest reproduced boundary and stop there.
Glossary
The small vocabulary that unlocks the whole framework
Plain-language definitions for manifests, resources, portable roots, anchors, carriers, viewers, revisions, and provenance.
- Manifest
- The signed packing list: what the work contains, how it opens, and what each resource must hash to.
- Resource
- One declared part of a work—HTML, CSS, code, image, audio, model, data, font, or another graph.
- Digest
- A fixed fingerprint of exact bytes. Change one byte and the digest changes.
- Portable root
- The chain-neutral identity of a canonical object or graph.
- Anchor
- A chain-specific record that binds a portable identity to a source, registry, and revision.
- Carrier
- Where encoded bytes are physically retrieved: a contract store, OnchFS, IPFS, Arweave, HTTPS, or a bundle.
- Viewer
- The host that resolves, verifies, and safely presents a work.
- Sandbox
- The isolated browser frame where creator code runs without inheriting the host wallet or raw network.
- Revision
- A numbered, inspectable presentation or object update with explicit lineage and policy.
- Provenance
- Evidence of where an object, revision, or source came from—not a marketing synonym for a URL.
Open the work. Keep the proof beside it.
Browse as a collector, or build a release with the guarantees you actually want to make.