Subscribe to Fabrica
<100 subscribers
Subscribe to Fabrica
<100 subscribers
FabricaThe rise of onchain land ownership.
A primer on buying and selling land NFTs, and the future of onchain land ownership.
FabricaCopy from us. The Fabrica Trust is open source.
It’s time to collaboratively build the future of real estate.
FabricaGuide to Lending on Fabrica Properties
An Overview for Lenders on Lending Against Onchain Real Estate Assets
FabricaThe rise of onchain land ownership.
A primer on buying and selling land NFTs, and the future of onchain land ownership.
FabricaCopy from us. The Fabrica Trust is open source.
It’s time to collaboratively build the future of real estate.
FabricaGuide to Lending on Fabrica Properties
An Overview for Lenders on Lending Against Onchain Real Estate Assets
Share Dialog
Share Dialog
If you are a Fabrica property owner and have lost control of your token, whether through lost keys, a compromised wallet, or the death of a keyholder, contact us at help@fabrica.land or on the chat on the website.
We will walk you through the recovery process and assist you at every step.
The rest of this article explains the design behind the recovery system: how it works, why we built it this way, and what protections are in place. If you are here because you need help now, start with the email above. The details can wait.
Fabrica links real property to a digital token through a legal trust. Whoever holds the token is the legal owner of the property. Transfer the token, transfer the ownership. Burn the token, dissolve the trust and take a traditional deed. It is elegant, fast, and cheap.
But it introduces a question that does not exist in traditional real estate: what happens if the owner loses access to their token?
In conventional property ownership, losing a deed does not mean losing the property. The county recorder maintains the record, and a new deed can be issued. But in Fabrica's system, the trust agreement requires the token to be burned before any property can leave the trust. If the owner cannot burn the token (because they lost their private key, the token got stuck in a malfunctioning smart contract, or the owner died without passing on wallet access), the property is locked in place with no exit path.
If you are a Fabrica property owner and have lost control of your token, whether through lost keys, a compromised wallet, or the death of a keyholder, contact us at help@fabrica.land or on the chat on the website.
We will walk you through the recovery process and assist you at every step.
The rest of this article explains the design behind the recovery system: how it works, why we built it this way, and what protections are in place. If you are here because you need help now, start with the email above. The details can wait.
Fabrica links real property to a digital token through a legal trust. Whoever holds the token is the legal owner of the property. Transfer the token, transfer the ownership. Burn the token, dissolve the trust and take a traditional deed. It is elegant, fast, and cheap.
But it introduces a question that does not exist in traditional real estate: what happens if the owner loses access to their token?
In conventional property ownership, losing a deed does not mean losing the property. The county recorder maintains the record, and a new deed can be issued. But in Fabrica's system, the trust agreement requires the token to be burned before any property can leave the trust. If the owner cannot burn the token (because they lost their private key, the token got stuck in a malfunctioning smart contract, or the owner died without passing on wallet access), the property is locked in place with no exit path.
This is not a hypothetical risk. As more properties are tokenized, the probability of at least one owner losing access to their keys approaches certainty. A system that has no answer for this scenario cannot be taken seriously by title insurance underwriters, institutional lenders, or any property owner thinking long term.
This article explains how we designed a failsafe to solve this problem: what we considered, what we chose, what we left out, and why.
Before exploring solutions, it helps to understand why this is harder than it looks.
The double-spend problem. If we make it easy to recover property without the token, we create a way for bad actors to exploit the system. A property owner could sell the token to a buyer, then go to the county recorder and claim they "lost" their keys, effectively getting the property back while the buyer holds a worthless token. Or worse: a borrower could pledge the token as collateral, take out a loan, then use the recovery mechanism to pull the property out from under the lender.
The collateral protection problem. Lending protocols accept Fabrica tokens as collateral. When a token is in a lending contract, the lender has a legal security interest in the underlying property. Any recovery mechanism must not allow the borrower to dissolve the trust and take the property while the lender is holding the token.
The independence problem. Fabrica's trust is designed to work even if Fabrica as a company ceases to exist. The trust agreement is open source, the smart contracts are permissionless, and property ownership does not depend on any centralized service. Any recovery mechanism must preserve this independence. We cannot introduce a "master key" or an admin function that gives any single entity the power to override property rights.
The legal recognition problem. Whatever mechanism we build must produce documents that a title insurance underwriter can follow and feel comfortable insuring. Title examiners review recorded documents at the county level. The recovery path needs to produce a coherent chain of title that a human reviewer (who may have never heard of blockchain) can understand.
These constraints eliminate most obvious solutions. You cannot just add an admin burn function to the smart contract (that violates independence). You cannot let the owner sign an offline recovery document (if they lost their keys, they cannot sign anything). You cannot rely solely on courts (too slow for uncontested cases and too expensive for low-value properties).
Before diving into the recovery mechanism, three concepts need explanation. They come up throughout this article and are central to how the system works in practice.
Validators are independent service providers that evaluate Fabrica tokens and publish a confidence score for each one. They monitor onchain activity (token transfers, contract interactions) and offchain records (county filings, title history, operating agreements) to produce a composite assessment of a token's health. Validators expose these scores both offchain (through APIs that lending protocols and marketplaces can query) and, in some cases, onchain (through oracle contracts that other smart contracts can read directly). Anyone can operate a validator. The trust agreement does not depend on any specific validator existing, but validators provide the real-time signal layer that connects legal events to the onchain ecosystem.
The confidence score is a multi-digit number that represents a validator's assessment of a token's status. Each digit captures a different dimension: title history, operating agreement quality, onchain activity, and (most significantly) the token's recovery status. Lending protocols, marketplaces, and other participants use the confidence score to make decisions. A protocol might require a minimum score before accepting a token as collateral. A marketplace might flag tokens with low scores. The score is not a legal determination. It is a risk signal, similar to a credit score for property tokens.
Void tokens. Onchain, a token is a token. The smart contract does not have a concept of "void." A void token is a token whose confidence score has been permanently degraded to a level that signals the property has been legally detached from the token through a recorded Deed of Distribution. The token still exists in the wallet, but every validator that examines the county records will see the deed and flag the token accordingly. Any protocol or marketplace checking the score will treat it as worthless. The legal dissociation happens at the county recorder; the confidence score is the mechanism that communicates it to the onchain world.
Not all key losses are the same. The appropriate response depends on the circumstances:
SCENARIO | CAN ANYONE MOVE THE TOKEN? | RISK OF FRAUD | APPROPRIATE RESPONSE |
|---|---|---|---|
Lost private key | No (token stays in the wallet) | Low | Self-service recovery with notice period |
Owner dies, keys lost | No | Low | Same, with estate documents |
Token stuck in a broken contract | Depends on the contract | Medium | Get token back to wallet first (if feasible), then self-service recovery |
Token stolen | Yes (thief has full control) | High | Court order required |
Owner dies, heirs inherit keys | No (heirs have keys) | None | No recovery needed; heirs are the new owner |
The key insight is that the level of risk determines the level of process. When no one can move the token, the risk of fraud is low, and a streamlined self-service process is appropriate. When someone has stolen the keys and can move the token at any time, only a court can sort out the competing claims.
We settled on a two-tier system: a self-service path for uncontested cases, and a court-order path for everything else.
For lost keys, stuck contracts, and estate situations where no one disputes who the rightful owner is.
The process is modeled on a quiet title action, a well-established legal procedure where a property owner files a public notice, waits for anyone to come forward with a competing claim, and if no one does, the court confirms ownership. Title insurance underwriters handle these regularly.
Here is the process:
Confirm the token is in an eligible location. The trust agreement (Section 10.2) requires that the Property Token is held by an Account (EOA) or a Section 7.3(a) Contract Account (essentially, a wallet or custody solution controlled by the Beneficiary). If the token is in a Section 7.3(b) functional contract (lending, escrow, collateral), the owner must first get it back, for example by paying off a loan, before initiating recovery. This is a structural gate that protects lenders and other counterparties without requiring any verification step.
Record a Notice of Lost Token Control at the county recorder where the property is located. This is a sworn affidavit (or equivalent sworn recordable instrument), executed under oath and notarized in whatever form the situs jurisdiction requires (acknowledgment, jurat, or equivalent). The Notice identifies the property, the token, and the circumstances of loss, and includes an attestation that the token is held by an Account or a 7.3(a) Contract Account. For estate cases, it also includes a death certificate and letters testamentary. Within ten days of recording, the claimant must deliver a copy of the recorded Notice by certified mail to: (a) the property address as shown in county tax records, and (b) each person who appears in the county recorder's official records as the holder of a recorded lien, deed of trust, mortgage, or other encumbrance against the property. Filing a false Notice constitutes perjury, a criminal act with a paper trail recorded at the county. If the county recorder refuses to accept the Notice for recording, the Beneficiary must proceed to the court-ordered path under Tier 2.
The 90-day quiet period begins on the date of recording. The recorded Notice constitutes constructive notice to the world of the Beneficiary's claim. Any interested party (lenders, purchasers, other claimants) may contest the Notice during this period by recording with the same county recorder any instrument permitted by applicable law that gives constructive notice of the contest, including but not limited to a lis pendens, a notice of pending action, an affidavit of adverse claim, or any equivalent instrument recognized by the recording statutes of the jurisdiction. A Notice of Lost Token Control recorded by a different claimant for the same token also constitutes a contest. To be effective, a contest must appear in the county records before the Quiet Period expires; filing a lawsuit alone, without a corresponding recorded instrument, does not halt the process. If a contest is recorded during the Quiet Period, the process immediately halts and the matter is resolved under Tier 2 (court order).
During the 90 days, the system watches for wallet activity:
If the wallet signs any transaction (not just a token transfer, but any onchain activity originated by the account), the process stops. A wallet that is transacting is not a wallet whose keys have been lost. Either the owner recovered access (good news) or someone else controls the wallet (escalate to Tier 2).
If nothing happens, continue to step 5.
After 90 days without wallet activity or contest, the Beneficiary delivers a sworn certificate to the Trustee confirming that: no transaction was initiated by the Account, no contest was recorded with the county recorder, and the Beneficiary complied with the notice-delivery requirements (including delivery to the property address and to each recorded lienholder, or that no lienholders were identified in the county's official records). The Trustee, at the Beneficiary's direction, then executes and delivers a Deed of Distribution transferring the property out of the trust. The deed recites the trust agreement's alternative dissolution provisions, the recording information of the Notice, and the Beneficiary's sworn certificate.
The deed is recorded at the county. The token becomes a Void Token: it still exists onchain, but it has been legally dissociated from the property. Anyone holding the void token has no property rights.
For theft, disputes, or any situation where Tier 1 cannot complete (for example, the token moved during the quiet period).
The owner petitions a court of competent jurisdiction for an order declaring the token lost, stolen, or inaccessible, and authorizing dissolution of the trust.
Standard judicial process applies: service of process, hearing, judgment. The court order substitutes for both the token burn and the cryptographic signature.
A Deed of Distribution is recorded with a certified copy of the court order attached. The token becomes a Void Token.
This is the path of last resort. It is slower and more expensive, but it handles the cases where someone is actively contesting ownership, exactly the kind of dispute that courts are designed to resolve.
Before initiating either tier, a theft victim can take one immediate action: submit a police report to the confidence score provider. The token gets flagged as "stolen" in the confidence score. This does not recover the property, but it functions as a digital stop-payment:
Lending protocols that check the confidence score will reject the token as collateral
Marketplaces can flag or hide the token
Any buyer or lender who proceeds despite the flag cannot later claim ignorance
This is similar to how OpenSea handles stolen NFTs: a flagged asset becomes commercially useless even though it still exists onchain. The goal is to make theft unprofitable.
One of the most practical use cases for this mechanism is estate succession.
If heirs inherit wallet access (through a seed phrase stored in a safe, with an estate attorney, or in a dead man's letter), they simply become the new owner. The trust agreement (Section 10.3.4) explicitly confirms that successors who inherit key access can exercise Owner Rights directly, including dissolving the Trust under Section 10.1. No special process needed.
If heirs do not have wallet access, they follow Tier 1. Instead of the owner filing the affidavit, the executor or heir does, attaching letters testamentary or equivalent proof of legal succession recorded alongside the Notice (Section 10.3.2). The proof of succession must be valid and sufficient under the laws of the jurisdiction where the property is located. If the legal successor cannot obtain sufficient proof in that jurisdiction, the dissolution must proceed through the court path under Section 10.4. Upon expiration of the Quiet Period, the legal successor steps into the Beneficiary's position for purposes of directing the Trustee to execute the Deed of Distribution (Section 10.3.3).
If heirs dispute among themselves, that is Tier 2. A probate court determines the rightful successor.
This approach works naturally because the recovery mechanism does not care why the keys were lost, only whether anyone can move the token. From the system's perspective, death-without-key-access and lost-key are the same problem.
The final design emerged from evaluating multiple approaches. Here is what else we looked at and why we did not pursue it.
The idea: When a property is first tokenized, the owner signs a recovery authorization that gets stored offchain. If they later lose their keys, they can present this document to recover the property.
Why we rejected it: The recovery authorization is signed by the same private key that controls the token. If the key is stolen, the thief has both the token and the recovery authorization. If the key is lost, the owner cannot produce the authorization because they cannot sign anything. The only scenario where it helps is when the owner loses their key but kept the signed document separately, a narrow benefit for the added complexity. We decided the marginal gain did not justify the process overhead of collecting and storing these documents for every token.
The idea: Add a "protector" to the trust, a designated party (possibly Fabrica or a third party) with the authority to intervene in specific situations, such as authorizing a recovery when keys are lost.
Why we rejected it: A trust protector introduces exactly the kind of centralization we are trying to avoid. The entire value proposition of Fabrica's trust is that it works independently: the trust agreement is open source, the smart contracts are permissionless, and ownership does not depend on any company remaining in business. A protector would create a single point of failure and a liability magnet. If the protector goes out of business, acts improperly, or is compromised, the trust breaks. Every function a protector would serve is already covered by the two-tier recovery mechanism: Tier 1 for uncontested cases, Tier 2 (courts) for contested ones.
The idea: Add a governance-controlled function to the smart contract that can burn or freeze tokens in specific circumstances, such as a multi-signature approval from designated parties.
Why we rejected it: This is the centralization problem in its most direct form. Anyone who can freeze or burn tokens without the holder's consent has the power to override property rights. This is fundamentally incompatible with the trust's design, which ensures that only the token holder can burn the token.
The idea: Prevent a thief from burning a stolen token and off-ramping the property through the standard dissolution path, by disabling the burn function when the confidence score indicates the token is stolen.
Why we rejected it: First, the standard off-ramp already requires identity verification and validator cooperation. A thief cannot silently burn a token and record a deed without the validator processing the off-ramp. Second, the real fraud vector for stolen tokens is not off-ramping (which requires interacting with the real-world legal system) but using the token as collateral in a lending protocol (which is entirely onchain). Disabling burns does not prevent collateral fraud. Third, disabling burns requires a smart contract change, which we scoped out. Fourth, a burn freeze could harm legitimate owners who are falsely flagged or who resolve a dispute.
The idea: Add an arbitration clause as a middle ground between the self-service Tier 1 and the full court process of Tier 2.
Why we deferred it: Arbitration works well for disputes between parties who have both agreed to it. In a theft scenario, the thief never consented to the trust agreement or its arbitration provisions, and arbitrators cannot bind non-consenting parties the way courts can through due process. We may add arbitration later as an optional intermediate step for disputes between known parties (for example, between co-owners who have both accepted the trust agreement), but it is not essential for the initial design.
The idea: Require token holders to periodically confirm they still have access (for example, sign a message every year). If they miss a heartbeat, trigger a recovery process automatically.
Why we did not include it: Interesting concept, but operationally impractical for most property owners. Requiring regular interactions with a blockchain wallet creates a maintenance burden that is foreign to how people think about property ownership. Missing a heartbeat should not put your property at risk. This may be worth revisiting later as an opt-in feature for sophisticated holders, but it should not be a default requirement.
Lender protection is structural, not procedural. It does not depend on any service provider checking anything.
The eligibility gate. The trust agreement (Section 10.2) requires that the Property Token be held by an Account (EOA) or a Section 7.3(a) Contract Account before Tier 1 can begin. Section 7.3(a) covers custody wallets (multi-sig wallets or similar solutions where the holder is the Beneficiary). Section 7.3(b) covers functional contracts (lending, escrow, collateral management, bridges) where custody does not confer beneficial ownership. If the token is in a lending contract, it is in a 7.3(b) Contract Account. The borrower simply cannot initiate Tier 1. They must first cause the token to be returned, typically by paying off the loan, before they can file a Notice. This works with any lending protocol because the eligibility gate is based on the onchain location of the token, not on any offchain verification.
Scenario: Borrower files a fraudulent notice. The Notice of Lost Token Control is a sworn affidavit that includes an attestation that the token is held by an Account or 7.3(a) Contract Account. Filing this when the token is verifiably in a lending contract is perjury with a paper trail at the county recorder. Even if a borrower lies, the 90-day Quiet Period gives the lender time to detect the situation. The lender or lending protocol can initiate any transaction from the wallet holding the token (triggering automatic process halt under Section 10.2.3) or record a contest (lis pendens, affidavit of adverse claim, or any equivalent instrument) with the county recorder, which immediately halts the process and routes to court.
Scenario: Stolen token used as collateral. A thief steals keys and immediately borrows against the token. The trust agreement (Section 11.4) explicitly protects the lender in this case: a party who obtains a security interest for value, in good faith, and without notice of the theft is a "protected secured party" whose position is not subordinated to the original owner's claim. The original owner's remedy is against the thief, not against the lender. This reflects a deliberate design choice: wallet security is the owner's responsibility (Section 7.5), and a lender who acted in good faith should not bear the cost of the owner's compromised keys.
The trust agreement's UCC Article 12 provisions add specificity here. Section 11.4 provides "qualifying purchaser" protection for good-faith transferees and "protected secured party" protection for good-faith lenders who obtain control of the token for value, without notice of competing claims. The Notice of Lost Token Control, recorded at the county, constitutes constructive notice that defeats both protections for anyone who acquires the token or extends credit after the notice is filed.
This means the owner's strongest move after discovering a theft is to file a Notice of Lost Token Control immediately. The moment the Notice is recorded, it triggers a confidence score downgrade from validators, which lending protocols can see in real time. Any lender who extends credit after the Notice is recorded cannot claim good-faith status under UCC Article 12. The faster the owner acts, the smaller the window in which a thief can exploit the token as collateral.
There is a question at the heart of Tier 1 that deserves a direct answer: when someone files a Notice claiming to be the owner of a wallet, how does anyone know they are telling the truth?
The trust agreement deliberately does not insert a gatekeeper into this process. No validator, platform, or service provider must verify the claim before the 90-day clock starts. This is by design: the legal mechanism must work even if the company that created it ceases to exist. Instead, it relies on a combination of deterrents, structural gates, and the passage of time.
The sworn affidavit. The Notice of Lost Token Control is a sworn affidavit, executed under oath and notarized in whatever form the situs jurisdiction requires. It includes an attestation that the token is held by an Account or a Section 7.3(a) Contract Account. Filing a false Notice is perjury, a criminal act with a permanent paper trail in the county records. This raises the stakes significantly for would-be fraudsters.
The eligibility gate. If the token is in a lending contract, escrow, or other functional contract (Section 7.3(b)), the process cannot begin at all. A fraudster cannot target a token that is actively being used as collateral.
The 90-day constructive notice. The recorded Notice constitutes constructive notice to the world. Anyone doing a title search will see it. Any interested party can contest. This mirrors how quiet title actions work: the public record is the notification mechanism, not a private service provider.
The passive owner problem. Consider this scenario: a legitimate owner holds a token in their wallet and simply does not interact with it for months. Someone files a fraudulent Notice against their wallet. The 90-day quiet period passes. The property gets pulled out of the trust. The real owner comes back six months later and discovers they have been robbed through the very mechanism designed to help people like them.
This is a real vulnerability. We mitigate it through several layers, but we do not fully eliminate it:
Perjury deterrent. The sworn Notice with a permanent county record creates criminal liability for false filings.
Physical delivery to the property address and lienholders. Within ten days of recording, the claimant must deliver a copy of the recorded Notice by certified mail to the property address as shown in county tax records and to each recorded lienholder identified in the county recorder's official records. This ensures that any occupant, passive owner, or existing creditor who does not monitor county filings still receives actual notice. Compliance with these delivery requirements must be attested in the sworn certificate.
The 90-day window. Three months is a long time. Most property owners interact with their assets (checking values, paying taxes, responding to offers) within that window. We chose 90 days specifically to balance speed for legitimate claimants against protection for passive holders.
Constructive notice via public record. The county recording is visible to anyone performing a title search, including title companies, lenders, and real estate professionals who interact with the property.
Platform-level notification (offchain service, not a legal requirement). As a practical matter, the confidence score provider monitors county records and can update the score and attempt to notify the current holder through available channels (email, platform notifications, onchain transaction to the wallet). This is a service-layer protection, not a trust agreement requirement. The legal mechanism works without it.
Trustee reliance safe harbor. The trust agreement (Section 8.2) allows the Trustee to rely on recorded documents without independent blockchain investigation, absent actual knowledge of fraud. In most Fabrica trusts, the Trustee and Beneficiary are the same person, which means the Trustee has direct knowledge of whether the claim is legitimate.
What we cannot solve: An owner who is completely disengaged (no registered email, no wallet monitoring, no interaction with the property for months) and who is targeted by a determined fraudster willing to commit perjury. This is the edge case where the system is most vulnerable. For such situations, Tier 2 (court order, with formal service of process) provides stronger protections.
We chose to be transparent about this limitation rather than pretend it does not exist. The alternative (requiring a gatekeeper to verify every recovery) would create a dependency on a specific entity and break the walk-away independence of the trust. The perjury deterrent, structural eligibility gate, and 90-day public notice period provide meaningful protection without introducing centralization.
We are intentional about the boundaries:
It does not prevent theft. The recovery mechanism responds to theft after the fact. It deters exploitation (through the confidence score flagging), provides a legal path to recover the property (through courts), and ensures the stolen token can be rendered worthless (through the void status). But it does not prevent someone from stealing private keys in the first place.
In the stolen-then-collateralized scenario, the owner bears the loss against a good-faith lender. When a thief borrows against a stolen token before the owner files a Notice, the trust agreement protects the lender's position (Section 11.4). The owner's remedy is against the thief, not the lender. This is a deliberate tradeoff: wallet security is the owner's responsibility, and lenders who acted in good faith should not absorb losses caused by compromised keys. The owner can limit this window by filing a Notice of Lost Token Control as quickly as possible, which triggers a confidence score downgrade and eliminates the lender's good-faith defense going forward.
It does not fully protect passive, unregistered owners. As discussed in the identity verification section, an owner who never registered with Fabrica, does not monitor their wallet, and has no contact information on file is the hardest to protect during the 90-day quiet period. The mitigations (sworn notice with perjury liability, structural eligibility gate, constructive notice via public record) reduce but do not eliminate this risk.
One attack we considered carefully: what if someone steals an owner's private key and, rather than transferring the token, simply operates from the owner's wallet? The attacker could borrow against the property, extract the loan proceeds, and disappear, all without triggering any token transfer that the confidence score could detect. The owner might not realize their keys were compromised until the loan defaults.
This is a real threat, but it is not one the trust agreement should address. The trust agreement governs the relationship between the property and the token: who the Beneficiary is, how the trust dissolves, what happens when token control is lost. Wallet security (how the owner protects access to their private key) is a different layer entirely.
The analogy to traditional real estate is direct. A property deed does not protect against someone forging the owner's signature on a mortgage application. That protection comes from identity verification at closing, notarization requirements, and the lender's own due diligence. The deed defines the property rights; it does not secure the owner's identity.
The same separation of concerns applies here:
The trust agreement defines the property-token relationship and provides recovery when token control is lost.
The wallet layer secures access to the private key through hardware wallets, multisig, two-factor authentication, and social recovery.
Lending protocols are responsible for their own borrower verification, just as traditional mortgage lenders are responsible for verifying the borrower's identity before disbursing funds.
For users of Fabrica's embedded wallet, we enforce two-factor authentication. This means that even if an attacker obtains the user's credentials, they cannot sign transactions without the second factor. Self-custody users who bring their own wallets are responsible for their own key management. That is the fundamental tradeoff of self-custody, and it applies to all onchain assets, not just tokenized property.
We deliberately chose not to embed wallet security requirements into the trust agreement. Doing so would couple the legal instrument to a specific technology stack, violate the independence principle (the trust must work regardless of what wallet the owner uses), and create a false sense of security. The trust agreement is the wrong layer to solve this problem, just as a deed is the wrong layer to mandate what kind of lock you put on your front door.
The trust agreement does, however, make the consequence of poor wallet security explicit. Section 7.5 states that the Beneficiary is responsible for maintaining the security of access to their Account. If a theft leads to an innocent lender being harmed, the lender's position is protected under Section 11.4, and the owner's remedy is against the thief. This creates the right incentives: owners are motivated to secure their keys, and lenders can extend capital with confidence that good-faith collateral positions are protected.
The entire framework is designed to produce documents that fit within existing title examination practices:
The Notice of Lost Token Control is a sworn affidavit recorded at the county, creating a cloud on title visible in any standard title search. Contests must also be recorded (lis pendens, affidavit of adverse claim, or equivalent instrument), keeping everything in the same public record. This mirrors the quiet title notice patterns that underwriters handle daily.
The 90-day quiet period is analogous to statutory notice periods in quiet title actions. Title examiners are familiar with waiting periods before title can be confirmed.
The Deed of Distribution is a standard recordable instrument with clear recitals explaining the alternative dissolution: the trust agreement provision, the recording information of the Notice, and the expiration of the Quiet Period without contest. The chain of title (original on-ramp deed > recorded Notice > passage of time > Deed of Distribution) is entirely documented in public records.
The court order path (Tier 2) produces the gold standard of title evidence. Court-ordered conveyances are a well-understood product in the title insurance industry.
No technology dependency. The entire chain of title can be examined by a title professional who has never heard of blockchain. Every document in the chain is a standard recorded instrument at the county recorder.
An underwriter evaluating a property that went through this process would see a coherent, documented chain with no gaps, no unexplained jumps, and no reliance on technology that the examiner needs to understand.
One of the principles we applied throughout the design: everything must work if Fabrica disappears.
The trust is independent. The smart contracts are permissionless. The trust agreement is on IPFS. But what about the recovery mechanism?
Tier 1 operates entirely through county recordings and the passage of time. The Beneficiary records a Notice, waits 90 days, and the Trustee executes a Deed of Distribution. No platform, validator, or service provider is a required participant in this legal process. The trust agreement (Section 10.5.2) explicitly states that offchain records like confidence scores are administrative convenience; the legal validity of the dissolution is established by the recorded Deed of Distribution alone.
Tier 2 goes through the court system, which is entirely independent of Fabrica.
The confidence score is an offchain service layer. It monitors county records, updates scores, and can attempt to notify token holders, all useful services, but none required by the trust agreement. If the scoring system disappears, the recorded Notice at the county still creates the legally operative cloud on title. Lending protocols would lose the real-time signal, but the legal process still works.
We deliberately avoided inserting any gatekeeper (a trust protector, a validator, an admin function) into the legal mechanism. The recovery works through public records and courts, institutions that predate blockchain and will outlast any company.
QUESTION | ANSWER |
What triggers recovery? | Owner cannot burn token (lost keys, stuck contract, death) |
Who can initiate? | The beneficiary or their legal successor |
What is the eligibility gate? | Token must be in EOA or 7.3(a) custody wallet, not in a 7.3(b) functional contract (lending, escrow, etc.) |
What is the uncontested path? | Record sworn affidavit at county + deliver to property address and recorded lienholders > 90-day quiet period > sworn certificate > Trustee executes Deed of Distribution |
What is the contested path? | Court order > Deed of Distribution |
How are lenders protected? | Structural eligibility gate (token in lending contract cannot enter Tier 1), direct certified mail notice to recorded lienholders, 90-day window, any recorded contest immediately halts process and routes to court, constructive notice on title, protected secured party status under UCC Article 12 (Section 11.4) |
What happens to the token? | It becomes a Void Token: still exists onchain, but legally meaningless under UCC Article 12 |
Does this require smart contract changes? | No |
Does this depend on Fabrica existing? | No. No validator, platform, or service provider is a required participant |
What risks remain? | Stolen-then-collateralized (owner bears loss against good-faith lender; owner's remedy is against the thief), passive unregistered owners (mitigated by perjury deterrent, eligibility gate, lienholder notice, and 90-day public notice) |
The recovery mechanism provides a clear, self-executing, legally grounded path for the most likely loss scenarios, without introducing any dependency on a specific company or service provider. It does not eliminate every risk (no system can). The edge cases that remain are the same ones that courts handle in traditional real estate.
For technical details, see the Fabrica Trust Agreement (open source) and Fabrica Documentation.
This blog post references directly to Fabrica Trust Agreement v4.2 as available on GitHub and IPFS. Future versions of the Trust Agreement might have different articles, sections and provisions.
This is not a hypothetical risk. As more properties are tokenized, the probability of at least one owner losing access to their keys approaches certainty. A system that has no answer for this scenario cannot be taken seriously by title insurance underwriters, institutional lenders, or any property owner thinking long term.
This article explains how we designed a failsafe to solve this problem: what we considered, what we chose, what we left out, and why.
Before exploring solutions, it helps to understand why this is harder than it looks.
The double-spend problem. If we make it easy to recover property without the token, we create a way for bad actors to exploit the system. A property owner could sell the token to a buyer, then go to the county recorder and claim they "lost" their keys, effectively getting the property back while the buyer holds a worthless token. Or worse: a borrower could pledge the token as collateral, take out a loan, then use the recovery mechanism to pull the property out from under the lender.
The collateral protection problem. Lending protocols accept Fabrica tokens as collateral. When a token is in a lending contract, the lender has a legal security interest in the underlying property. Any recovery mechanism must not allow the borrower to dissolve the trust and take the property while the lender is holding the token.
The independence problem. Fabrica's trust is designed to work even if Fabrica as a company ceases to exist. The trust agreement is open source, the smart contracts are permissionless, and property ownership does not depend on any centralized service. Any recovery mechanism must preserve this independence. We cannot introduce a "master key" or an admin function that gives any single entity the power to override property rights.
The legal recognition problem. Whatever mechanism we build must produce documents that a title insurance underwriter can follow and feel comfortable insuring. Title examiners review recorded documents at the county level. The recovery path needs to produce a coherent chain of title that a human reviewer (who may have never heard of blockchain) can understand.
These constraints eliminate most obvious solutions. You cannot just add an admin burn function to the smart contract (that violates independence). You cannot let the owner sign an offline recovery document (if they lost their keys, they cannot sign anything). You cannot rely solely on courts (too slow for uncontested cases and too expensive for low-value properties).
Before diving into the recovery mechanism, three concepts need explanation. They come up throughout this article and are central to how the system works in practice.
Validators are independent service providers that evaluate Fabrica tokens and publish a confidence score for each one. They monitor onchain activity (token transfers, contract interactions) and offchain records (county filings, title history, operating agreements) to produce a composite assessment of a token's health. Validators expose these scores both offchain (through APIs that lending protocols and marketplaces can query) and, in some cases, onchain (through oracle contracts that other smart contracts can read directly). Anyone can operate a validator. The trust agreement does not depend on any specific validator existing, but validators provide the real-time signal layer that connects legal events to the onchain ecosystem.
The confidence score is a multi-digit number that represents a validator's assessment of a token's status. Each digit captures a different dimension: title history, operating agreement quality, onchain activity, and (most significantly) the token's recovery status. Lending protocols, marketplaces, and other participants use the confidence score to make decisions. A protocol might require a minimum score before accepting a token as collateral. A marketplace might flag tokens with low scores. The score is not a legal determination. It is a risk signal, similar to a credit score for property tokens.
Void tokens. Onchain, a token is a token. The smart contract does not have a concept of "void." A void token is a token whose confidence score has been permanently degraded to a level that signals the property has been legally detached from the token through a recorded Deed of Distribution. The token still exists in the wallet, but every validator that examines the county records will see the deed and flag the token accordingly. Any protocol or marketplace checking the score will treat it as worthless. The legal dissociation happens at the county recorder; the confidence score is the mechanism that communicates it to the onchain world.
Not all key losses are the same. The appropriate response depends on the circumstances:
SCENARIO | CAN ANYONE MOVE THE TOKEN? | RISK OF FRAUD | APPROPRIATE RESPONSE |
|---|---|---|---|
Lost private key | No (token stays in the wallet) | Low | Self-service recovery with notice period |
Owner dies, keys lost | No | Low | Same, with estate documents |
Token stuck in a broken contract | Depends on the contract | Medium | Get token back to wallet first (if feasible), then self-service recovery |
Token stolen | Yes (thief has full control) | High | Court order required |
Owner dies, heirs inherit keys | No (heirs have keys) | None | No recovery needed; heirs are the new owner |
The key insight is that the level of risk determines the level of process. When no one can move the token, the risk of fraud is low, and a streamlined self-service process is appropriate. When someone has stolen the keys and can move the token at any time, only a court can sort out the competing claims.
We settled on a two-tier system: a self-service path for uncontested cases, and a court-order path for everything else.
For lost keys, stuck contracts, and estate situations where no one disputes who the rightful owner is.
The process is modeled on a quiet title action, a well-established legal procedure where a property owner files a public notice, waits for anyone to come forward with a competing claim, and if no one does, the court confirms ownership. Title insurance underwriters handle these regularly.
Here is the process:
Confirm the token is in an eligible location. The trust agreement (Section 10.2) requires that the Property Token is held by an Account (EOA) or a Section 7.3(a) Contract Account (essentially, a wallet or custody solution controlled by the Beneficiary). If the token is in a Section 7.3(b) functional contract (lending, escrow, collateral), the owner must first get it back, for example by paying off a loan, before initiating recovery. This is a structural gate that protects lenders and other counterparties without requiring any verification step.
Record a Notice of Lost Token Control at the county recorder where the property is located. This is a sworn affidavit (or equivalent sworn recordable instrument), executed under oath and notarized in whatever form the situs jurisdiction requires (acknowledgment, jurat, or equivalent). The Notice identifies the property, the token, and the circumstances of loss, and includes an attestation that the token is held by an Account or a 7.3(a) Contract Account. For estate cases, it also includes a death certificate and letters testamentary. Within ten days of recording, the claimant must deliver a copy of the recorded Notice by certified mail to: (a) the property address as shown in county tax records, and (b) each person who appears in the county recorder's official records as the holder of a recorded lien, deed of trust, mortgage, or other encumbrance against the property. Filing a false Notice constitutes perjury, a criminal act with a paper trail recorded at the county. If the county recorder refuses to accept the Notice for recording, the Beneficiary must proceed to the court-ordered path under Tier 2.
The 90-day quiet period begins on the date of recording. The recorded Notice constitutes constructive notice to the world of the Beneficiary's claim. Any interested party (lenders, purchasers, other claimants) may contest the Notice during this period by recording with the same county recorder any instrument permitted by applicable law that gives constructive notice of the contest, including but not limited to a lis pendens, a notice of pending action, an affidavit of adverse claim, or any equivalent instrument recognized by the recording statutes of the jurisdiction. A Notice of Lost Token Control recorded by a different claimant for the same token also constitutes a contest. To be effective, a contest must appear in the county records before the Quiet Period expires; filing a lawsuit alone, without a corresponding recorded instrument, does not halt the process. If a contest is recorded during the Quiet Period, the process immediately halts and the matter is resolved under Tier 2 (court order).
During the 90 days, the system watches for wallet activity:
If the wallet signs any transaction (not just a token transfer, but any onchain activity originated by the account), the process stops. A wallet that is transacting is not a wallet whose keys have been lost. Either the owner recovered access (good news) or someone else controls the wallet (escalate to Tier 2).
If nothing happens, continue to step 5.
After 90 days without wallet activity or contest, the Beneficiary delivers a sworn certificate to the Trustee confirming that: no transaction was initiated by the Account, no contest was recorded with the county recorder, and the Beneficiary complied with the notice-delivery requirements (including delivery to the property address and to each recorded lienholder, or that no lienholders were identified in the county's official records). The Trustee, at the Beneficiary's direction, then executes and delivers a Deed of Distribution transferring the property out of the trust. The deed recites the trust agreement's alternative dissolution provisions, the recording information of the Notice, and the Beneficiary's sworn certificate.
The deed is recorded at the county. The token becomes a Void Token: it still exists onchain, but it has been legally dissociated from the property. Anyone holding the void token has no property rights.
For theft, disputes, or any situation where Tier 1 cannot complete (for example, the token moved during the quiet period).
The owner petitions a court of competent jurisdiction for an order declaring the token lost, stolen, or inaccessible, and authorizing dissolution of the trust.
Standard judicial process applies: service of process, hearing, judgment. The court order substitutes for both the token burn and the cryptographic signature.
A Deed of Distribution is recorded with a certified copy of the court order attached. The token becomes a Void Token.
This is the path of last resort. It is slower and more expensive, but it handles the cases where someone is actively contesting ownership, exactly the kind of dispute that courts are designed to resolve.
Before initiating either tier, a theft victim can take one immediate action: submit a police report to the confidence score provider. The token gets flagged as "stolen" in the confidence score. This does not recover the property, but it functions as a digital stop-payment:
Lending protocols that check the confidence score will reject the token as collateral
Marketplaces can flag or hide the token
Any buyer or lender who proceeds despite the flag cannot later claim ignorance
This is similar to how OpenSea handles stolen NFTs: a flagged asset becomes commercially useless even though it still exists onchain. The goal is to make theft unprofitable.
One of the most practical use cases for this mechanism is estate succession.
If heirs inherit wallet access (through a seed phrase stored in a safe, with an estate attorney, or in a dead man's letter), they simply become the new owner. The trust agreement (Section 10.3.4) explicitly confirms that successors who inherit key access can exercise Owner Rights directly, including dissolving the Trust under Section 10.1. No special process needed.
If heirs do not have wallet access, they follow Tier 1. Instead of the owner filing the affidavit, the executor or heir does, attaching letters testamentary or equivalent proof of legal succession recorded alongside the Notice (Section 10.3.2). The proof of succession must be valid and sufficient under the laws of the jurisdiction where the property is located. If the legal successor cannot obtain sufficient proof in that jurisdiction, the dissolution must proceed through the court path under Section 10.4. Upon expiration of the Quiet Period, the legal successor steps into the Beneficiary's position for purposes of directing the Trustee to execute the Deed of Distribution (Section 10.3.3).
If heirs dispute among themselves, that is Tier 2. A probate court determines the rightful successor.
This approach works naturally because the recovery mechanism does not care why the keys were lost, only whether anyone can move the token. From the system's perspective, death-without-key-access and lost-key are the same problem.
The final design emerged from evaluating multiple approaches. Here is what else we looked at and why we did not pursue it.
The idea: When a property is first tokenized, the owner signs a recovery authorization that gets stored offchain. If they later lose their keys, they can present this document to recover the property.
Why we rejected it: The recovery authorization is signed by the same private key that controls the token. If the key is stolen, the thief has both the token and the recovery authorization. If the key is lost, the owner cannot produce the authorization because they cannot sign anything. The only scenario where it helps is when the owner loses their key but kept the signed document separately, a narrow benefit for the added complexity. We decided the marginal gain did not justify the process overhead of collecting and storing these documents for every token.
The idea: Add a "protector" to the trust, a designated party (possibly Fabrica or a third party) with the authority to intervene in specific situations, such as authorizing a recovery when keys are lost.
Why we rejected it: A trust protector introduces exactly the kind of centralization we are trying to avoid. The entire value proposition of Fabrica's trust is that it works independently: the trust agreement is open source, the smart contracts are permissionless, and ownership does not depend on any company remaining in business. A protector would create a single point of failure and a liability magnet. If the protector goes out of business, acts improperly, or is compromised, the trust breaks. Every function a protector would serve is already covered by the two-tier recovery mechanism: Tier 1 for uncontested cases, Tier 2 (courts) for contested ones.
The idea: Add a governance-controlled function to the smart contract that can burn or freeze tokens in specific circumstances, such as a multi-signature approval from designated parties.
Why we rejected it: This is the centralization problem in its most direct form. Anyone who can freeze or burn tokens without the holder's consent has the power to override property rights. This is fundamentally incompatible with the trust's design, which ensures that only the token holder can burn the token.
The idea: Prevent a thief from burning a stolen token and off-ramping the property through the standard dissolution path, by disabling the burn function when the confidence score indicates the token is stolen.
Why we rejected it: First, the standard off-ramp already requires identity verification and validator cooperation. A thief cannot silently burn a token and record a deed without the validator processing the off-ramp. Second, the real fraud vector for stolen tokens is not off-ramping (which requires interacting with the real-world legal system) but using the token as collateral in a lending protocol (which is entirely onchain). Disabling burns does not prevent collateral fraud. Third, disabling burns requires a smart contract change, which we scoped out. Fourth, a burn freeze could harm legitimate owners who are falsely flagged or who resolve a dispute.
The idea: Add an arbitration clause as a middle ground between the self-service Tier 1 and the full court process of Tier 2.
Why we deferred it: Arbitration works well for disputes between parties who have both agreed to it. In a theft scenario, the thief never consented to the trust agreement or its arbitration provisions, and arbitrators cannot bind non-consenting parties the way courts can through due process. We may add arbitration later as an optional intermediate step for disputes between known parties (for example, between co-owners who have both accepted the trust agreement), but it is not essential for the initial design.
The idea: Require token holders to periodically confirm they still have access (for example, sign a message every year). If they miss a heartbeat, trigger a recovery process automatically.
Why we did not include it: Interesting concept, but operationally impractical for most property owners. Requiring regular interactions with a blockchain wallet creates a maintenance burden that is foreign to how people think about property ownership. Missing a heartbeat should not put your property at risk. This may be worth revisiting later as an opt-in feature for sophisticated holders, but it should not be a default requirement.
Lender protection is structural, not procedural. It does not depend on any service provider checking anything.
The eligibility gate. The trust agreement (Section 10.2) requires that the Property Token be held by an Account (EOA) or a Section 7.3(a) Contract Account before Tier 1 can begin. Section 7.3(a) covers custody wallets (multi-sig wallets or similar solutions where the holder is the Beneficiary). Section 7.3(b) covers functional contracts (lending, escrow, collateral management, bridges) where custody does not confer beneficial ownership. If the token is in a lending contract, it is in a 7.3(b) Contract Account. The borrower simply cannot initiate Tier 1. They must first cause the token to be returned, typically by paying off the loan, before they can file a Notice. This works with any lending protocol because the eligibility gate is based on the onchain location of the token, not on any offchain verification.
Scenario: Borrower files a fraudulent notice. The Notice of Lost Token Control is a sworn affidavit that includes an attestation that the token is held by an Account or 7.3(a) Contract Account. Filing this when the token is verifiably in a lending contract is perjury with a paper trail at the county recorder. Even if a borrower lies, the 90-day Quiet Period gives the lender time to detect the situation. The lender or lending protocol can initiate any transaction from the wallet holding the token (triggering automatic process halt under Section 10.2.3) or record a contest (lis pendens, affidavit of adverse claim, or any equivalent instrument) with the county recorder, which immediately halts the process and routes to court.
Scenario: Stolen token used as collateral. A thief steals keys and immediately borrows against the token. The trust agreement (Section 11.4) explicitly protects the lender in this case: a party who obtains a security interest for value, in good faith, and without notice of the theft is a "protected secured party" whose position is not subordinated to the original owner's claim. The original owner's remedy is against the thief, not against the lender. This reflects a deliberate design choice: wallet security is the owner's responsibility (Section 7.5), and a lender who acted in good faith should not bear the cost of the owner's compromised keys.
The trust agreement's UCC Article 12 provisions add specificity here. Section 11.4 provides "qualifying purchaser" protection for good-faith transferees and "protected secured party" protection for good-faith lenders who obtain control of the token for value, without notice of competing claims. The Notice of Lost Token Control, recorded at the county, constitutes constructive notice that defeats both protections for anyone who acquires the token or extends credit after the notice is filed.
This means the owner's strongest move after discovering a theft is to file a Notice of Lost Token Control immediately. The moment the Notice is recorded, it triggers a confidence score downgrade from validators, which lending protocols can see in real time. Any lender who extends credit after the Notice is recorded cannot claim good-faith status under UCC Article 12. The faster the owner acts, the smaller the window in which a thief can exploit the token as collateral.
There is a question at the heart of Tier 1 that deserves a direct answer: when someone files a Notice claiming to be the owner of a wallet, how does anyone know they are telling the truth?
The trust agreement deliberately does not insert a gatekeeper into this process. No validator, platform, or service provider must verify the claim before the 90-day clock starts. This is by design: the legal mechanism must work even if the company that created it ceases to exist. Instead, it relies on a combination of deterrents, structural gates, and the passage of time.
The sworn affidavit. The Notice of Lost Token Control is a sworn affidavit, executed under oath and notarized in whatever form the situs jurisdiction requires. It includes an attestation that the token is held by an Account or a Section 7.3(a) Contract Account. Filing a false Notice is perjury, a criminal act with a permanent paper trail in the county records. This raises the stakes significantly for would-be fraudsters.
The eligibility gate. If the token is in a lending contract, escrow, or other functional contract (Section 7.3(b)), the process cannot begin at all. A fraudster cannot target a token that is actively being used as collateral.
The 90-day constructive notice. The recorded Notice constitutes constructive notice to the world. Anyone doing a title search will see it. Any interested party can contest. This mirrors how quiet title actions work: the public record is the notification mechanism, not a private service provider.
The passive owner problem. Consider this scenario: a legitimate owner holds a token in their wallet and simply does not interact with it for months. Someone files a fraudulent Notice against their wallet. The 90-day quiet period passes. The property gets pulled out of the trust. The real owner comes back six months later and discovers they have been robbed through the very mechanism designed to help people like them.
This is a real vulnerability. We mitigate it through several layers, but we do not fully eliminate it:
Perjury deterrent. The sworn Notice with a permanent county record creates criminal liability for false filings.
Physical delivery to the property address and lienholders. Within ten days of recording, the claimant must deliver a copy of the recorded Notice by certified mail to the property address as shown in county tax records and to each recorded lienholder identified in the county recorder's official records. This ensures that any occupant, passive owner, or existing creditor who does not monitor county filings still receives actual notice. Compliance with these delivery requirements must be attested in the sworn certificate.
The 90-day window. Three months is a long time. Most property owners interact with their assets (checking values, paying taxes, responding to offers) within that window. We chose 90 days specifically to balance speed for legitimate claimants against protection for passive holders.
Constructive notice via public record. The county recording is visible to anyone performing a title search, including title companies, lenders, and real estate professionals who interact with the property.
Platform-level notification (offchain service, not a legal requirement). As a practical matter, the confidence score provider monitors county records and can update the score and attempt to notify the current holder through available channels (email, platform notifications, onchain transaction to the wallet). This is a service-layer protection, not a trust agreement requirement. The legal mechanism works without it.
Trustee reliance safe harbor. The trust agreement (Section 8.2) allows the Trustee to rely on recorded documents without independent blockchain investigation, absent actual knowledge of fraud. In most Fabrica trusts, the Trustee and Beneficiary are the same person, which means the Trustee has direct knowledge of whether the claim is legitimate.
What we cannot solve: An owner who is completely disengaged (no registered email, no wallet monitoring, no interaction with the property for months) and who is targeted by a determined fraudster willing to commit perjury. This is the edge case where the system is most vulnerable. For such situations, Tier 2 (court order, with formal service of process) provides stronger protections.
We chose to be transparent about this limitation rather than pretend it does not exist. The alternative (requiring a gatekeeper to verify every recovery) would create a dependency on a specific entity and break the walk-away independence of the trust. The perjury deterrent, structural eligibility gate, and 90-day public notice period provide meaningful protection without introducing centralization.
We are intentional about the boundaries:
It does not prevent theft. The recovery mechanism responds to theft after the fact. It deters exploitation (through the confidence score flagging), provides a legal path to recover the property (through courts), and ensures the stolen token can be rendered worthless (through the void status). But it does not prevent someone from stealing private keys in the first place.
In the stolen-then-collateralized scenario, the owner bears the loss against a good-faith lender. When a thief borrows against a stolen token before the owner files a Notice, the trust agreement protects the lender's position (Section 11.4). The owner's remedy is against the thief, not the lender. This is a deliberate tradeoff: wallet security is the owner's responsibility, and lenders who acted in good faith should not absorb losses caused by compromised keys. The owner can limit this window by filing a Notice of Lost Token Control as quickly as possible, which triggers a confidence score downgrade and eliminates the lender's good-faith defense going forward.
It does not fully protect passive, unregistered owners. As discussed in the identity verification section, an owner who never registered with Fabrica, does not monitor their wallet, and has no contact information on file is the hardest to protect during the 90-day quiet period. The mitigations (sworn notice with perjury liability, structural eligibility gate, constructive notice via public record) reduce but do not eliminate this risk.
One attack we considered carefully: what if someone steals an owner's private key and, rather than transferring the token, simply operates from the owner's wallet? The attacker could borrow against the property, extract the loan proceeds, and disappear, all without triggering any token transfer that the confidence score could detect. The owner might not realize their keys were compromised until the loan defaults.
This is a real threat, but it is not one the trust agreement should address. The trust agreement governs the relationship between the property and the token: who the Beneficiary is, how the trust dissolves, what happens when token control is lost. Wallet security (how the owner protects access to their private key) is a different layer entirely.
The analogy to traditional real estate is direct. A property deed does not protect against someone forging the owner's signature on a mortgage application. That protection comes from identity verification at closing, notarization requirements, and the lender's own due diligence. The deed defines the property rights; it does not secure the owner's identity.
The same separation of concerns applies here:
The trust agreement defines the property-token relationship and provides recovery when token control is lost.
The wallet layer secures access to the private key through hardware wallets, multisig, two-factor authentication, and social recovery.
Lending protocols are responsible for their own borrower verification, just as traditional mortgage lenders are responsible for verifying the borrower's identity before disbursing funds.
For users of Fabrica's embedded wallet, we enforce two-factor authentication. This means that even if an attacker obtains the user's credentials, they cannot sign transactions without the second factor. Self-custody users who bring their own wallets are responsible for their own key management. That is the fundamental tradeoff of self-custody, and it applies to all onchain assets, not just tokenized property.
We deliberately chose not to embed wallet security requirements into the trust agreement. Doing so would couple the legal instrument to a specific technology stack, violate the independence principle (the trust must work regardless of what wallet the owner uses), and create a false sense of security. The trust agreement is the wrong layer to solve this problem, just as a deed is the wrong layer to mandate what kind of lock you put on your front door.
The trust agreement does, however, make the consequence of poor wallet security explicit. Section 7.5 states that the Beneficiary is responsible for maintaining the security of access to their Account. If a theft leads to an innocent lender being harmed, the lender's position is protected under Section 11.4, and the owner's remedy is against the thief. This creates the right incentives: owners are motivated to secure their keys, and lenders can extend capital with confidence that good-faith collateral positions are protected.
The entire framework is designed to produce documents that fit within existing title examination practices:
The Notice of Lost Token Control is a sworn affidavit recorded at the county, creating a cloud on title visible in any standard title search. Contests must also be recorded (lis pendens, affidavit of adverse claim, or equivalent instrument), keeping everything in the same public record. This mirrors the quiet title notice patterns that underwriters handle daily.
The 90-day quiet period is analogous to statutory notice periods in quiet title actions. Title examiners are familiar with waiting periods before title can be confirmed.
The Deed of Distribution is a standard recordable instrument with clear recitals explaining the alternative dissolution: the trust agreement provision, the recording information of the Notice, and the expiration of the Quiet Period without contest. The chain of title (original on-ramp deed > recorded Notice > passage of time > Deed of Distribution) is entirely documented in public records.
The court order path (Tier 2) produces the gold standard of title evidence. Court-ordered conveyances are a well-understood product in the title insurance industry.
No technology dependency. The entire chain of title can be examined by a title professional who has never heard of blockchain. Every document in the chain is a standard recorded instrument at the county recorder.
An underwriter evaluating a property that went through this process would see a coherent, documented chain with no gaps, no unexplained jumps, and no reliance on technology that the examiner needs to understand.
One of the principles we applied throughout the design: everything must work if Fabrica disappears.
The trust is independent. The smart contracts are permissionless. The trust agreement is on IPFS. But what about the recovery mechanism?
Tier 1 operates entirely through county recordings and the passage of time. The Beneficiary records a Notice, waits 90 days, and the Trustee executes a Deed of Distribution. No platform, validator, or service provider is a required participant in this legal process. The trust agreement (Section 10.5.2) explicitly states that offchain records like confidence scores are administrative convenience; the legal validity of the dissolution is established by the recorded Deed of Distribution alone.
Tier 2 goes through the court system, which is entirely independent of Fabrica.
The confidence score is an offchain service layer. It monitors county records, updates scores, and can attempt to notify token holders, all useful services, but none required by the trust agreement. If the scoring system disappears, the recorded Notice at the county still creates the legally operative cloud on title. Lending protocols would lose the real-time signal, but the legal process still works.
We deliberately avoided inserting any gatekeeper (a trust protector, a validator, an admin function) into the legal mechanism. The recovery works through public records and courts, institutions that predate blockchain and will outlast any company.
QUESTION | ANSWER |
What triggers recovery? | Owner cannot burn token (lost keys, stuck contract, death) |
Who can initiate? | The beneficiary or their legal successor |
What is the eligibility gate? | Token must be in EOA or 7.3(a) custody wallet, not in a 7.3(b) functional contract (lending, escrow, etc.) |
What is the uncontested path? | Record sworn affidavit at county + deliver to property address and recorded lienholders > 90-day quiet period > sworn certificate > Trustee executes Deed of Distribution |
What is the contested path? | Court order > Deed of Distribution |
How are lenders protected? | Structural eligibility gate (token in lending contract cannot enter Tier 1), direct certified mail notice to recorded lienholders, 90-day window, any recorded contest immediately halts process and routes to court, constructive notice on title, protected secured party status under UCC Article 12 (Section 11.4) |
What happens to the token? | It becomes a Void Token: still exists onchain, but legally meaningless under UCC Article 12 |
Does this require smart contract changes? | No |
Does this depend on Fabrica existing? | No. No validator, platform, or service provider is a required participant |
What risks remain? | Stolen-then-collateralized (owner bears loss against good-faith lender; owner's remedy is against the thief), passive unregistered owners (mitigated by perjury deterrent, eligibility gate, lienholder notice, and 90-day public notice) |
The recovery mechanism provides a clear, self-executing, legally grounded path for the most likely loss scenarios, without introducing any dependency on a specific company or service provider. It does not eliminate every risk (no system can). The edge cases that remain are the same ones that courts handle in traditional real estate.
For technical details, see the Fabrica Trust Agreement (open source) and Fabrica Documentation.
This blog post references directly to Fabrica Trust Agreement v4.2 as available on GitHub and IPFS. Future versions of the Trust Agreement might have different articles, sections and provisions.
No comments yet