Silvetus is a permissionless registry of long-lived trees on the Base blockchain. Each tree in the registry is represented by a non-fungible token. The token is transferable while the tree is alive. When the tree dies, the token freezes, permanently non-transferable, permanently non-recoverable. The intended consequence is that holders of tokens have a continuous, asynchronous interest in the survival of specific trees, and that this interest, distributed across many holders and many trees, adds a continuous form of protective pressure to the discrete, episodic, exhausting work of conservation.
Traditional conservation is the work of people who know what is at stake. They know the biomes collapse without the old trees. They have been doing this work for a hundred years and the work is harder every year.
This protocol does not replace them. It brings them reinforcement of a different kind: a group of people whose own financial position is now bound to specific trees being alive. The motivation is different. The direction is the same.
More energy. More vitality. More drive in the same direction. This is what we are about.
No. Claiming a tree mints a token whose metadata references that tree’s coordinates, species, and estimated age. The token references the tree. It does not own the tree. Referencing is not claiming, in the property-law sense. Observing is not owning. The protocol does not interact with the property regime that governs the land the tree stands on, and the holder of a token has no rights in the physical tree, the land, or any other thing that legal systems recognize as property. What the holder has is a digital token whose continued tradeability is contingent on the continued life of a specific tree somewhere in the world.
No. The protocol takes nothing on sales between holders. There is no royalty, no transfer fee, no protocol-side hook of any kind on a transfer between two participants. This is one of the three rules the protocol commits to: the protocol takes nothing on sales, ever. The verification pool funds itself through other flows, recertification fees and claim fees, both paid by people actively engaging the protocol’s operational mechanisms rather than by people merely trading.
Two flows, both endogenous.
Recertification fees: every twenty-five years, the holder of each token must recertify the token by confirming that the tree referenced is still alive. The recertification fee is paid by the holder at that moment.
Claim fees: paid when a participant either admits a new tree to the registry (under the user-submission flow) or claims a dead-tree token under the protocol’s death-claim mechanism. The claim fee is structurally higher than the recertification fee, by an immutable fifty-percent displacement premium, reflecting the higher operational cost of admitting versus maintaining.
Both flows route to the verification pool. No external dependency, no transfer fee, no oracle-priced mechanism. The pool is healthy when the protocol is in active use.
The state a token enters when the tree it references is reported and confirmed dead. A frozen token is permanently non-transferable. No transaction, no governance decision, no coordinated action of any kind can transfer it again. It persists in the wallet of its last holder as a permanent record of the tree it referenced. The freeze is one-way: there is no recovery, no salvage, no compensation.
This is by design. The financial interest in the tree’s survival is total precisely because no portion of the holder’s investment is recoverable upon failure. A protocol that allowed partial recovery would dilute the incentive structure that the freeze exists to create.
It depends on what bad means. Yes, the holder of a frozen token has lost the ability to transfer that token to anyone else for any consideration. That is a financial loss in the conventional sense.
And the freeze is the mechanism by which the protocol’s claim to align self-interest with conservation actually operates. A holder whose tree dies has experienced the consequence the protocol promised they would experience. The mechanism worked. The tree died despite the holder’s interest in its survival, which is unfortunate, but the mechanism’s correctness is not contingent on every individual outcome, it’s contingent on the structure of incentives the mechanism produces across the registry as a whole. Across many holders and many trees, the freeze is what keeps the incentive real.
Not exactly. Speculation is a bet on an outcome you can’t influence. This is different in kind: a bet you can, to some extent, make come true.
A holder whose financial position is bound to a specific tree being alive is now a person who might send the email to their congressman that they would never have sent before. Might fund a local land trust. Might show up to a zoning hearing. In cases where the capital at stake is large, proper lobbying becomes worthwhile in a way it never was when the only argument was moral.
The mechanism is not predicting that trees survive. It is making more people want them to, and giving those people a reason to act. That is what separates this from speculation, and it is the point of the design.
AT-251 v0.3, deployed on Base mainnet in May 2026. Both the token contract and the verification pool are source-verified on BaseScan. The contract designation is fixed, the 251 encodes the age threshold (two hundred and fifty-plus years), not a version number. v0.3 is the specific deployment iteration. Earlier iterations existed during design; AT-251 v0.3 is the operational protocol.
A single oracle wallet, operated by the founder. This is phase one of a three-phase roadmap. Phase one is, by design, the most centralized configuration the protocol will ever have. The reason for this configuration is operational, not philosophical: at small registry scale, integrity is best maintained by a single careful operator with appropriate tooling, and distributing oracle authority across multiple parties at this scale would increase coordination cost without commensurate benefit. The trade-off is real, phase one accepts a centralization risk, and the protocol commits, openly and visibly, to three rules that constrain what the operator will and won’t do with that centralization.
Three commitments that constrain the protocol’s operational behavior. They are not enforced by the contract; they are enforced by discipline, made publicly visible so that any deviation is immediately legible.
Rule one: the genesis collection is sealed at exactly eleven trees. The oracle wallet holds the eleven genesis tokens and will hold no others. Any future tokens admitted to the registry, through any flow, mint to addresses other than the oracle wallet.
Rule two: the protocol takes nothing on sales between holders. Ever. No royalties, no transfer fees, no protocol-side hooks on transfers. The pool funds itself from recertifications and claims only.
Rule three: ownership of the contract will move toward distributed control, not be renounced. The contract’s ownership migrates from founder to multisig in phase two, and from multisig to a permissionless verification mechanism in phase three. It will not be renounced at any point. An unowned contract cannot transition to its next phase, and the protocol’s intended longevity depends on being able to perform such transitions.
Three phases. Each phase transitions to the next when specific conditions, triggers, not dates, have been satisfied.
Phase one (current): single oracle wallet, founder-operated. Submissions reviewed by an automated coordinate sense-checker and by the founder. The eleven genesis trees are deployed; user submissions are admitted by review.
Phase two, multisignature oversight: triggered when the registry has grown to a size at which single-operator review is no longer sufficient, the multisig group has assembled, and the verification process has been documented to the standard of a written specification. Authority moves to a multisig with a threshold that permits founder recusal, no signature from the founder is structurally required. Walletless onboarding lands at phase two: submitted trees become claimable without a crypto wallet.
Phase three, permissionless verification: triggered when the pool has self-funded for twelve months without subsidy, a verifier population sufficient to bootstrap the Schelling game’s economic dynamics has formed, and ten or more active verifiers have demonstrated independent capability. Oracle authority is replaced by a permissionless mechanism. The founder becomes a regular user of the protocol.
Each phase’s required capability is provisioned by the same conditions that necessitate the phase. The multisig is unnecessary while one careful operator suffices, becomes necessary as the registry grows, and the registry grows by attracting the participants who themselves become the multisig signers. The same shape applies at the next transition. The protocol’s scaling does not depend on a separate scaling effort.
Because contract renunciation is sometimes proposed as a credibility signal, a way to say your tokens are now safe from the founder’s discretion. In this protocol, renunciation would be the opposite of credibility. It would mean the contract can no longer migrate to phase two, or phase three, and the protocol would be permanently locked at whatever level of decentralization existed at the moment of renunciation. The right move toward distributed control is not to abandon the wheel; it is to add hands to it on a schedule, with the founder’s hands moving away last. Rule three names this commitment.
The freeze mechanism eliminates the most obvious version of this attack: no one profits from reporting a tree dead, because the token freezes and becomes worthless to its holder, and no one else acquires anything in the process. There is no buyer-of-the-frozen-token, no liquidation, no salvage value. The reporter doesn’t gain by reporting falsely; the holder loses by being reported against; and the protocol loses by admitting an invalid report. Everyone’s interest is in accurate reporting.
That doesn’t eliminate griefing entirely, a malicious actor with no financial stake in the registry could still flood the system with junk reports designed to create operational overhead. The phase-one verification architecture handles this by requiring oracle confirmation before any freeze takes effect. Phase three’s Schelling game handles it through stake-and-challenge economics that make junk reports actively costly to submit. Each phase’s response to griefing is engineered to its operational scale.
An automated software agent that supports the founder’s review of submitted trees in phase one. Given a submitted set of coordinates and a claimed species and age, the agent runs a series of consistency checks against publicly available data sources, high-resolution satellite imagery, IUCN species-distribution polygons, treeline and elevation models, registries of named significant trees maintained by national parks services and botanical organizations. The agent does not make admissibility decisions. It produces a structured report that flags candidates warranting human attention and that the founder reviews before accepting submissions to the mintable set.
The point of the agent is not automation for its own sake. It is to make the founder’s review tractable at scale. A single careful operator cannot personally inspect a hundred thousand candidate locations against satellite imagery. An operator assisted by an agent that does the first pass and surfaces the cases that matter, can. The agent allocates human judgment to where human judgment matters.
No. The protocol references trees; it does not own them, claim them, or assert any property right over them. The token is a digital reference to a physical entity. The reference confers no rights in the physical entity. A holder of a token cannot prevent the landowner from cutting the tree, cannot enter the land where the tree stands, cannot file legal claims against the cutting on the basis of the token, and cannot, in any jurisdiction known to the protocol’s authors, assert any property right of any kind by virtue of holding the token.
If a landowner cuts a tree referenced by a token, the token freezes. The cutter doesn’t profit from the cut in any way the protocol mediates; the holder loses the value of the token; the protocol records the freeze. No legal interaction, no jurisdictional collision. The protocol is operationally compatible with every property regime that exists, because it does not interact with property regimes at all.
The pressure flows through markets, advocacy, purchase offers, conservation easements that token holders might fund, public attention that holders might generate, through every legitimate channel, none of them adversarial to the property regime.
The system hibernates. The pool drains. Verification stops. Tokens reach their twenty-five-year recertification deadline without being recertified, and their alive-status flags become subject to re-examination by whatever verification mechanism is current. Trades may continue at the contract level, but the registry’s claim to reflect ground-truth tree status weakens with every unchecked recertification cycle.
The hibernation state is recoverable. If activity resumes, recertifications start being paid again, the pool refills, verifiers return, the protocol returns to its operational mode. The death-freeze mechanism remains armed throughout: a tree confirmed dead during a hibernation period still freezes its token, irrevocably.
The hibernation state is, in a real sense, the protocol’s failure mode at long time horizons. The protocol does not promise this never happens. It promises that if it happens, the failure is graceful: tokens persist, the freeze remains correct for any tree confirmed dead, and the protocol can be resumed by participants who choose to resume it.
Not directly through a self-service flow yet, that’s part of phase two, when walletless onboarding lands. In phase one, new trees enter the registry through a submission-and-review flow: you submit the coordinates of an old-growth tree, the sense-checker and the founder review the submission, and admitted trees are added to the mintable set. When walletless onboarding ships, submitters whose trees have been admitted will be able to claim those trees first, without needing a crypto wallet of their own.
The eleven genesis trees that already exist on the registry are held in the founder’s oracle wallet. They are not currently for sale through the protocol. If the founder elects to sell any of the eleven on a secondary market, that sale would happen on whatever NFT marketplace supports the contract, but as of this writing, none of the genesis tokens have been listed.
Through an app someone else builds.
The protocol is composable infrastructure — a contract on Base mainnet with public methods, an open registry, and no user interface of its own. Anyone can build on top of it. A conservation-app version might let you walk through a forest and see which nearby old-growth trees are in the registry, claim unregistered trees on the spot, or follow specific trees in your area. A concept of what that could look like is published at /raices on this site.
Raíces is not built, not operated, and not endorsed by Silvetus. It is a hypothetical third-party application — published as a concept to demonstrate what the open protocol enables. We deliberately do not build it ourselves, because doing so would make Silvetus a product company, and the protocol is designed to be infrastructure that others build products on.
Use the submission form on silvetus.com. You’ll need: GPS coordinates of the tree (latitude and longitude, decimal format); the species, if you know it; an estimated age, with the basis for the estimate (named-tree registry, dendrochronological study, photograph series, local knowledge, be honest about the source); and a contact email so the protocol can reach you when the submission is reviewed.
Submissions go to the sense-checker first, which produces a structured report on plausibility. The founder reviews submissions that pass the first-pass screening. Submissions that pass review are added to the mintable set; submissions that fail are responded to with the specific reason for rejection, in case the submitter has additional information that addresses it.
Submitted trees are not, themselves, registered on chain at the moment of submission. Registration happens at the moment of mint, which is a separate event downstream, currently the founder mints in phase one, and the submitter will be able to mint themselves through the walletless flow in phase two.
In phase one, you can submit a tree (no wallet required) or you can email the protocol to express interest in participation. Phase two will introduce a custodial onboarding flow that creates a wallet on your behalf, server-side, when you claim a tree, you will not need to interact with the standard crypto-wallet creation process. The custodial flow is engineered to allow participants without prior blockchain experience to acquire and hold tokens; it is a phase-two capability, not a phase-one capability. If you want to be notified when phase two ships, the submission form has a checkbox for that.
No. AT-251 tokens are not investment contracts. The protocol does not promise that the tokens will appreciate in value, that they will be tradeable on any particular market, that the registry will grow, that the value of any one tree’s token will bear any particular relationship to the value of any other tree’s token, or that any holder will be able to transact their token at any particular price. Whatever value the tokens have in any market is a market phenomenon, produced by the participants in that market. The protocol observes this phenomenon. The protocol does not produce it and does not commit to producing it.
If you are considering acquiring a token because you expect it to appreciate, please do not. The mechanism is designed to align the holder’s interest with the tree’s survival; it is not designed to produce returns. Holders whose primary interest is appreciation will be disappointed by the protocol’s deliberate refusal to take any action whose purpose is to produce appreciation. The right reason to acquire a token is to acquire an asset whose continued tradeability depends on a specific tree’s survival, because you want the tree to survive.
The whitepaper. It’s published as a downloadable document at silvetus.com/whitepaper, with version number on the title page and the related Research Notes referenced in the Related work section. The Research Notes themselves are published with persistent DOIs at Zenodo. The contracts are source-verified on BaseScan; addresses are in the whitepaper’s Appendix A and on the homepage’s proof section. The protocol’s correspondence address is hart.mitchell@gmail.com for press inquiries; substantive technical questions are best directed there with Silvetus in the subject line.
Direct question, fair to ask. Several things you can check independently.
The contracts exist on Base mainnet at the addresses published on the homepage. You can read the source on BaseScan, both contracts are source-verified. You can see the eleven genesis tokens in the oracle wallet by querying the contract directly.
The protocol takes no fees on transfers between holders. You can verify this by reading the source: there is no royalty hook, no transfer fee implementation. If the protocol attempted to introduce one in a future contract update, the update would be visible on chain and the introduction would constitute a breach of the publicly stated rules.
The genesis cohort is sealed at eleven. You can verify the count of tokens in the oracle wallet at any time. If the count grows beyond eleven without an explanatory contract upgrade and a published rationale, that’s a breach of the publicly stated rules and you should treat it as such.
The roadmap to phase two and phase three has named triggers, not dates. The triggers are operational conditions you can observe, registry size, multisig assembly, verifier population. The protocol’s transitions through phases are not vague and are not under discretionary timelines.
None of this constitutes a guarantee that the protocol will succeed at its claimed purpose. It constitutes evidence that the protocol’s claims are testable. The protocol is real in the sense that the contracts are deployed and the rules are visible. Whether it succeeds at the larger work, adding meaningful protective pressure to old-growth trees, is a longer empirical question that the registry’s growth and the trees’ survival rates will eventually answer.
Email the protocol at hart.mitchell@gmail.com. Subject line Silvetus helps. Substantive technical questions, ethical concerns, criticisms of the design, and questions about participation are all welcome. The FAQ is iterated as questions accumulate; if your question is one others have likely asked, it will probably appear in a future version.