Every valuation now comes with a downloadable report. When FabricaAVM values a parcel, it now generates a multi-page PDF valuation report and attaches it to the token, so borrowers and lenders can see how an estimate was reached instead of only the headline number. The report covers the property's characteristics (including lot size, zoning, access, topography, and surrounding-area context), a map of the parcel alongside the comparable sales the estimate drew on with a table of those comparables, the model's output and confidence together with which parcel characteristics pushed the value up or down, and a plain-language methodology and limitations section that names the data sources behind the estimate. It is regenerated whenever the model re-runs for a parcel, so it always reflects the current estimate, and it is retrievable through the API so integrators can surface it too. In the Fabrica app, you can now download the report directly from a property's price details.
The public marketplace and profiles now show only marketplace-grade properties. Browsing the marketplace or viewing a public profile now surfaces only properties whose confidence score clears the marketplace-grade threshold, so what appears on these public pages is limited to tokens whose link to the underlying property is well verified. Low-scoring or flagged tokens no longer show up in the public marketplace grid, and they no longer count toward a profile's parcel totals or appear on its map. Owners still see every property they hold in their own portfolio view, including any that sit below the threshold.
Buyers are now warned when two tokens claim the same parcel. If a property references the same county parcel (the same assessor parcel number and holding entity) as one or more other tokens, the marketplace now shows a clear "duplicate claim" warning, because a single deed can belong to only one owner and at most one of those tokens represents the real property. The warning appears on the property page, as a ribbon on the property's marketplace card, on the map, and again in the purchase flow, prompting you to confirm the deed and current ownership before buying so you are not misled into purchasing a competing claim.
Accepting an offer and reading activity feeds both work more cleanly. Accepting an offer now reliably completes in one go, because the flow grants the marketplace the approval it needs as part of the same action instead of silently missing that step. Separately, property and profile activity feeds are clearer: routine "configuration updated" entries no longer bury or overwrite the specific event that actually happened, and picture updates now show a thumbnail of what changed.
Redeeming from the lending pool is more reliable. Capital providers redeeming a deposit from the Fabrica lending pool no longer get stuck on a spinning confirmation when a network response is slow; the app now retries the receipt and, if it genuinely cannot confirm, surfaces a clear error and a retry instead of appearing to hang indefinitely. A newly booked redemption also shows up immediately in your pending withdrawals, even in the brief window before the data indexer catches up with the chain, so redeemed funds are never left invisible.
Refinancing a loan works reliably for in-app accounts again. Refinancing a loan against a Fabrica property now refreshes the signed valuation quote at the moment of submission, fixing a failure that could stop the transaction from going through for people using an account created inside the app. Those owners can now refinance without landing on an error screen.
Loan track records read correctly again. Repaid and refinanced loans no longer appear as "defaulted" on public profiles and property activity feeds, and repayment-rate statistics count them as repaid. Previously a loan that was paid off, often well before its due date, or rolled into a replacement loan could be recorded under a different internal identifier than its origination, so the activity pipeline failed to pair the two and marked the loan defaulted once the original maturity date passed, even though it had been settled and no liquidation ever occurred. Loan pairing now reconciles a loan's origination against its repayment or refinancing across those mismatched identifiers, the way the underlying onchain records already do, so a borrower's history reflects what actually happened.

Changelog