September 2026

Put your property up for sale the moment you start adding it. Adding a property no longer reads as a waiting period. While the add-a-property steps run in the background, the property page now leads with a "Sell this property" card: set your price and go live, and the paperwork happens at closing, or sooner if you want to enable instant sales. The percent-complete checklist is gone, replaced by a compact status strip that stays quiet while photos, description, and title history are prepared, speaks up only when a step actually needs you, and presents document signing as an invitation once your paperwork is ready: sign now to enable instant purchases and borrowing, or wait until a buyer commits. Once the token is issued, a listing created earlier can be confirmed with a single signature to become instantly purchasable, and that confirmation now performs the marketplace approval it needs and is shown to the account that actually created the listing. The emails sent during the process were rewritten to match: they lead with your property page being live rather than with steps still to come.

Integrations can now read why borrowing is unavailable for a property. The public GraphQL API's poolLendingLiquidity object now carries a structured appraisalBlockReason field alongside the maximum loan amount. When a property does not qualify for a pool loan and the reason can be shared, the field states it as an enum value: the property's tax status has not been verified as current (TAX_STATUS_UNKNOWN) or its taxes are verified past due (TAX_DELINQUENT); the enum also reserves a general OTHER value for future reasons. The field is null otherwise. This is the same signal behind the "borrowing isn't available" explanation on the property page, so anything built on the API can show owners an accurate availability message instead of inferring one, and can rely on new reason values being added over time without existing ones being removed or renamed.

Buyer inquiries from outside listing sites now reach you reliably and privately. Listings distributed beyond the Fabrica marketplace now carry a dedicated Fabrica contact address on every listing instead of the seller's email, so your address is no longer part of the listing's published contact details. When a buyer inquires on an outside site, Fabrica verifies that the message genuinely comes from that listing service and forwards it to your inbox with the buyer set as the reply address, so answering is as simple as replying to an email; the buyer also receives a reply pointing to your property page on Fabrica. If a listing service changes its notification format, the inquiry is forwarded to you as received rather than dropped. Seller names on outside sites also display correctly now: accounts without a profile name appear as "Property Owner" instead of blank or placeholder text.

Adding photos to a property works again, and file names keep their extensions. For a few days in mid-September, every new photo or video added through the property page's media dialog was rejected, while removing existing media still worked. The app was sending files without their type and with the extension stripped from the name, and a stricter server-side check on accepted file types then refused them. The app now sends each file with its real type and an intact extension, and the server infers the type from the file name when a client sends none, so uploads from other API clients are protected as well. Two files whose names sanitize to the same value are given distinct names instead of one silently overwriting the other, and a WebP image added to a property that already has its token no longer fails the whole batch. Unsupported formats, including SVG, are still refused with a message naming the file.

Valuations now find comparable sales in counties where parcel-number formats differ between data sources. The valuation model excludes any comparable sale whose parcel boundary is unknown, and boundaries come from a parcel-record lookup by county and parcel number. In some counties, one data source formats the parcel number differently from another, so that lookup returned no match, the parcel was recorded as not found for a year, and the set of usable comparables could collapse to nothing, leaving the property with no estimate at all. When the exact-number lookup finds nothing and the parcel's coordinates are known, the lookup now falls back to the coordinates, which returns the same parcel under its canonical number and restores the full comparable set. A temporary rate limit from a data source is also no longer mistaken for a missing parcel.

Adding a property recovers from a failed notarization or recording submission instead of stalling. Two late steps in adding a property depend on outside services: the online notarization session and the electronic submission of signed documents to the county. If the notarization request failed to start, or the county's e-recording service refused the submission, the step used to sit in progress indefinitely with no way to retry it. Both steps now retry on their own, a submission that is refused outright is marked as failed rather than left looking as if it were out for recording, and either step can be resumed from where it stopped. Exactly one notarization session is created for a document package even when two earlier steps complete at the same moment, so the same documents are never sent for notarization twice.

Paying off a loan is no longer hidden by a finished bank payment. The property page's loan section, including the Pay Off Loan action, is meant to step aside only while a bank-funded purchase is still settling. The check behind it counted finished bank payments too, so an owner whose property had any completed bank payment in its history could hold a live loan and see no way to pay it off. Only a payment that is actually still in flight hides the loan section now.

Adding a property by parcel number now resolves to the county you selected. The same assessor parcel number can exist in several counties of one state, and the lookup used to take the first statewide match, so a property could be created with one county's records and another county's coordinates. The lookup is now scoped to the county you picked, says clearly when no matching parcel exists there instead of substituting one from elsewhere, and selecting a parcel from the map now carries the correct county as well.

The off-ramp authorization step now works reliably for external wallets. Owners taking a property back to a traditional deed sign an authorization along the way. For accounts connected through an external wallet, that signature could fail with a connection error even after earlier steps had succeeded. The signing step now talks to the connected wallet directly, and when a connection genuinely is lost it shows a clear message with the way to reconnect instead of a technical error.

A blocked purchase now names its actual reason. When a purchase is refused because the property does not meet the marketplace's verification requirements, the message used to combine two possible causes in a single either/or sentence, so a property refused over title verification alone showed a passing confidence score next to words suggesting a score failure. The message now states exactly which requirement was not met.

Document generation now stops on missing information instead of shipping placeholders. When a value a legal document template needs could not be resolved, generation used to render literal placeholder text into a notarization-ready document, and optional parts of a signer's name could appear as the word "null". Generation now detects a required value that is missing wherever it appears in the template, requests the missing information, and refuses to produce the document until every value resolves; signer lines are composed only from the parts that carry a value. Regenerating a document package also cancels the superseded signing session, so only the current set of documents can be signed.

Connect an AI agent to live Fabrica data with a URL. The Fabrica MCP server, which gives AI agents read-only access to properties, the lending market, portfolios, and protocol statistics over the Model Context Protocol, is now hosted at https://mcp.fabrica.land/mcp (Ethereum mainnet) and https://mcp-testnet.fabrica.land/mcp (Sepolia testnet). There is nothing to install and no API key: paste the URL into Claude, Claude Code, Cursor, or any client that supports remote MCP servers. The network is fixed per URL, so an agent connected to the testnet server can never reach mainnet data, and the same eleven tools remain available locally from the public repository. Earlier in the month, property lookups were repaired after a renamed API field had made every property-detail request fail and report the property as not found; the server now reports an API failure as an error distinct from a missing property, and the mainnet legal guidance it carries for agents now reaches the connected client, which it previously did not. Because the former peer-to-peer lending integration has shut down, borrow quotes no longer list peer-to-peer offers; loan history, including past peer-to-peer loans, is unchanged. See AI agents and MCP.

Ask an AI assistant about a property and get a card you can act on. In clients that support MCP Apps, such as Claude on the web and in the desktop app, a property lookup through the Fabrica MCP server now renders as a property card instead of a block of text: the parcel map and the owner's photos, the name, location and acreage, the confidence score, estimated value, listing price and borrowing capacity, and buttons to buy, make an offer, contact the owner, or open the property on Fabrica. Every button leads to the property's page on Fabrica, where the action is completed and signed with the user's own account; the server itself stays read-only and never prepares a transaction. Property details now also include the owner's photos and parcel map image links for clients that show the data as text. In the same release, every tool declares itself read-only in the standard MCP way, so assistants that confirm before running state-changing tools treat Fabrica lookups as plain reads; the mainnet legal notice is stated as facts about the trust and the token holder's obligations, with the trustee designated by the holder and by default the holder, rather than as instructions to the assistant; lending figures name the in-app lending pool, label loans made through the former peer-to-peer integration as retired, state loan volume per currency, and round a borrowing capacity down to whole USDC so it never overstates; and portfolio lookups are scoped to the network the server is connected to. fabrica.land/llms.txt now lists the hosted server URLs so agents can find them without reading the documentation. See AI agents and MCP.

Manage your property's photos in one place: reorder, pick the cover, caption, and see every upload progress. The property page's media dialog was rebuilt. Photos and videos sit in a grid where each one can be captioned inline (up to 255 characters), marked for removal and restored with one click before saving, and, while the property is still being added, dragged into order (keyboard included) or promoted to the cover buyers see first. Files are checked before anything is sent: images except SVG and videos up to 100 MB are accepted, and a "Heads up" notice names each rejected file and why while the valid ones still go through. Saving shows each stage as it happens, with per-file upload progress, and a failed step keeps your edits and says what went wrong instead of discarding them. For developers, media entries in the configuration object now carry the display order the owner chose, and the GraphQL API returns configuration.media sorted by it, with unordered entries last.

Required yes/no questions in the add-a-property form now behave. A required dropdown question is announced to screen readers by its question alone, reports a missing choice as "Please choose an answer", rejects a value that is not one of its options, and restores the owner's saved answer when they return to the step, scoped to that property and account so an answer can never be submitted for a different property.

Only you can read your in-progress add-a-property answers. A read of an add-a-property record is now redacted unless it comes from the owner's signed-in session: it keeps the property's public location, parcel data, media, status, and steps (without signing links), and says only whether an email and recipients exist, not what they are. Off-ramp and proof-of-ownership records are now returned only to their owner. An add-a-property record started before signing in is claimed with a one-time secret that the server keeps only as a hash, and the app's API route now forwards only the exact routes the app uses. For integrators, this is the API's 2.0 release: OnRampDto gains hasEmail, hasRecipients, and sessionId, its email, recipients, and collectedFields are present only on owner reads, the on-ramp PATCH accepts an X-On-Ramp-Session header, and the off-ramp endpoints accept a user session as well as an API bearer. The On-Ramp section of the API reference describes the access model.

A lien check that could not run no longer counts as passed. The weekly title and lien validation reads an open-lien report for each property. When that report was unavailable, the "no liens found" check used to be recorded as a pass. It is now left unknown, which earns no points in the past-title group of the confidence score, and the gap is logged for follow-up, so a score never reports a clean lien check on the strength of a missing report. A zero balance still passes and a positive balance still fails.

Removing a photo or document from a property being added now matches by content. Before the token is issued, a media or document removal sent to the configuration endpoint had to quote the stored ipfs:// source exactly, so a removal using the gateway URL the API itself returns was silently ignored with a 200. Removals now match by CID across the ipfs:// and gateway forms, as they already did for issued tokens, a removal that matches nothing returns 422 naming the source, and document sources are validated to the same two forms on every write.