Ask the difficult questions.

Traent connects the asset's physical condition, legal identity and financial life to their sources, versions, validators and access rules. The result is a living record that authorised people can verify and reuse across operations, due diligence, finance, assurance and—when appropriate—regulated digital issuance.

A virtual data room helps people share documents, and a document management system helps them store documents. Traent adds provenance, version history, responsible parties, validation status and role-based access. It is designed to keep that evidence useful after one transaction, so the next decision does not start from an empty folder. Traent can complement existing systems rather than replace them.

They are composable modules of the Traent platform, each specialised for a different area, for the acquisition, organisation and processing of real-estate data: the Physical Twin covers the asset's physical and operational reality, the Legal Twin its legal and documentary identity, the Capital Twin its financial life. They do not create rights on their own: they connect information, sources, attestations and responsibilities to the relevant process.

Collateral Evidence is the organised set of sources, dates, validators, changes and access permissions connected to an asset. It makes the origin and status of information easier to reconstruct. It is not simply a data room, and it does not replace valuation, due diligence, credit decisions, KYC/AML checks or professional responsibility.

The Asset Token identifies the asset and links it to authorised evidence from its Twins. It can support sale, credit, management, insurance and control without any financial issuance. It does not, by itself, transfer ownership of the property or create an investment right.

A Transparent Token is a security token described by its approved issuance documents and issued through authorised parties. Because it qualifies as a financial instrument, it sits under the EU financial-markets framework (MiFID II), not under MiCA. It is linked to the asset's Asset Token so eligible viewers can verify authorised evidence about the underlying asset. Its rights come from the issuer, contracts and applicable law—not from the technology alone.

The Transparent Token is the financial instrument. The Asset Token is not a financial instrument: it identifies the asset and links it to its data, which constitute its Collateral Evidence. The Asset Token can optionally be connected to a Transparent Token, but it can also be used without any financial issuance — for sale, credit, management, insurance and control.

Physical, Legal and Capital Twins can support ordinary asset management, sale, due diligence, lending, insurance, monitoring and public oversight. A regulated digital instrument is an optional path built on the same verified base—not a prerequisite for using it.

Blockchain can make integrity, timing, authorship and later changes verifiable. It cannot decide whether an original statement was substantively correct. That depends on the source, the validator and the process behind it. In evidentiary terms, an anchored record works alongside the European eIDAS framework—qualified timestamps and electronic seals—which is the most direct EU reference for proving when a record existed and that it has not changed since.

No. Traent's blockchain was designed to guarantee complete management of access restrictions to data. The owner and the entitled parties define the perimeter, purpose, duration and recipients of access; GDPR, professional secrecy, contractual constraints and sector rules continue to apply.

Authorised users can consult the environment continuously, and enabled sources can submit updates when events occur. Each field should show its source, latest update and validation status. A planning permission, valuation or lease only becomes current when the responsible source updates or validates it.

Mirroring is designed to show the authorised, updateable state of selected information. A Digital Passport is a selected snapshot certified at a defined date. Both are permissioned: different people can receive different views of the same underlying evidence according to their role and purpose.

A correction must not erase the history. Traent's blockchain allows data to be corrected, but does so in a way that never deletes its history. The system keeps version, author, reason, validation status and the chain of changes; governance rules define who may correct, attest or suspend the use of a piece of data.

Different evidence requires different responsible parties: public registers, owners, lawyers, notaries, technicians, property managers, valuers, banks or payment sources. Traent records provenance and process. It does not automatically assume the regulated or professional role of the person who validates the underlying fact.

A new lease, permit, valuation, payment or construction milestone can update the authorised record and trigger the relevant review workflow. Material events may also require disclosure or another decision by the responsible parties. Financial rights change only through the applicable contracts and procedures.

Missing, outdated or conflicting material can be classified, assigned to an owner and placed in a remediation plan. Even a partial archive becomes easier to search and audit, but an absent source remains absent. A pilot on a real sample is the right way to measure the starting quality and the work required.

Traent's blockchain uses proprietary technology that allows data to be included directly in-chain while guaranteeing the same usage scenarios that would be obtained by placing them off-chain — with the great advantage of having everything managed within a single homogeneous system. The traditional off-chain technique is also supported and can be used if required; placing some data off-chain, however, would not allow their use within Digital Passports.

There are several anchoring cases. The Asset Token can optionally be anchored to a Transparent Token. The Collateral Evidence is anchored to an Asset Token. And the Collateral Evidence is anchored on a public blockchain: every 24 hours, the digest of a verifiable persistent data structure that cryptographically describes the evolution of the data constituting the Collateral Evidence is written on a public blockchain, as the note field of a transaction cryptographically signed by the account linked to Traent — without exposing the data itself in any way.

Cloud infrastructure for the Traent blockchain and the real-estate products — compute and data storage — is located in the EU. AI model inference currently runs through the APIs of the model providers (OpenAI and Anthropic); EU-hosted model routes can be evaluated on request. The AI tooling (vector store and agent orchestration) was selected so that it can be brought into Traent's EU cloud when required.

AI can help classify documents, extract selected information, answer questions over authorised sources and run predefined checks that support reports. In real estate, domain structures guide the system toward sector-specific documents and fields. AI accelerates the work; it does not become the final legal, technical or financial decision-maker.

Traent can use retrieval-augmented generation (RAG): the system searches the user's authorised documents and structured data, then uses the relevant material to prepare an answer. The useful part is not a fluent sentence alone; it is the connection back to the evidence the user can inspect.

In Traent's technical vocabulary it means that the input, output, agent, time and workflow steps of an AI process can be recorded and anchored verifiably. Traent's blockchain was built to create publicly verifiable audit logs of the execution of business processes, and we chose to use that capability also when AI tools process data: by saving on the Traent blockchain both the input data and the execution of the AI workflows, results become verifiable and traceable, in line with the principles of trustworthy AI.

It is not a notarial act and it does not replace a notary, a professional or a competent authority.

The approach is retrieval-augmented generation anchored to the uploaded documents: answers come with a reference to the source, so the operator can always verify the origin of the data. In addition, the AI system is enriched with techniques based on real-estate sector ontologies, also with the aim of reducing hallucinations. The RAG assistant is currently used in guided commercial demonstrations; dedicated guardrail systems are part of the roadmap ahead of broad client use.

Yes. In the real-estate product, human-in-the-loop review is part of the flow: users are shown the classification of the documents and the extracted data, together with a confidence estimate for the operation, and can manually correct the results or explicitly accept them. The AI assists; the user stays in control of what is retained. Traent is measuring actual error rates to further calibrate the confidence estimate.

A generated answer or extracted field should be treated according to its source, validation status and intended use. Traent can make the AI process more traceable, but it does not transfer professional responsibility to the model or turn a model output into a legal attestation.

The AI agents use frontier LLMs via API — currently OpenAI and Anthropic models. Client documents processed by the AI are not used to train the providers' models and are protected by the business-grade agreements in place; Traent does not use ambiguous providers and applies practices to prevent shadow AI by its staff. Cloud infrastructure for the Traent blockchain and the real-estate products — compute and storage — is located in the EU; AI model inference currently runs through the providers' APIs. Zero-data-retention and EU-hosted model options can be evaluated on request. Data separation between clients is physical between environments and logical between tenants within the same environment.

Traent's verification model publishes a cryptographic digest—a one-way fingerprint—not the underlying business content. Documents and data remain in the controlled environment, subject to their access controls. The exact distribution of controlled data, references and public anchors is documented for the relevant product and deployment.

Sources, versions, attestations and updates can remain connected to the asset and be reused within the bank's accepted perimeter. The credit committee keeps full autonomy; Traent makes the evidence easier to interrogate and the history easier to reconstruct.

Loan-to-value (LTV) and debt-service coverage ratio (DSCR) remain bank-defined metrics. Traent can organise their inputs, validation status, calculation rules and changes so a user can understand what supports the current figure. It does not automatically determine value, creditworthiness or the bank's decision.

A work-progress certificate—often called SAL in Italy—site evidence and agreed conditions can be connected to the relevant approval process. Escrow releases or drawdowns remain decisions of the bank or appointed agent. No payment is released merely because a datum exists on the platform.

Due diligence still requires judgement, current checks and responsibility from the relevant professionals. Traent can reduce repeated document collection and reconciliation when the evidence is current and accepted by the parties. Any time or cost reduction must be measured against an explicit baseline and scope.

The benefit is that the valuer and the transaction team may start from organised, attributable and current evidence instead of reconstructing the full file. The bank and the professional still decide which inspections, updates and valuation work are required.

Currently there are no integrations ready out-of-the-box. It is, however, possible to build custom integrations, based on APIs, with other platforms — everything in the Traent blockchain goes through publicly documented APIs.

A full export (including the master key) serves as a personal backup: you keep your data, and it remains independently verifiable forever against the public-chain trace using the open-source, published verification logic — no Traent involvement needed. Verification of an export needs only the export file, the public verification logic and the digest sequence on the public blockchain.

The quality of asset evidence, the legal rights of an instrument and its investment performance are separate questions. Traent does not guarantee value, return, liquidity, issuer solvency or the absence of loss.

A token can represent debt, equity or another instrument. Connection to an Asset Token does not itself transfer direct ownership of real estate. Ownership, ranking and economic rights come from the applicable registers, issuer and contracts.

Liquidity still depends on eligible buyers, demand, instrument structure, permitted venues, custody, settlement, transfer restrictions and market conditions. A more verifiable underlying asset may improve decision quality, but it does not guarantee a buyer or a price.

Technical transferability is not the same as legal permission to trade. The authorised venue or transfer process, eligible investors, jurisdictions, lock-ups and other restrictions must be stated in the approved issuance documents.

Issuance, distribution, investor eligibility, custody, transfer, trading, settlement and servicing remain with the issuer and other authorised parties named in the documentation. Traent provides the Twins, evidence controls, access layer and Asset Token that can support those processes.

Coupon or return, maturity, seniority, security package, covenants and payment waterfall must be read in the term sheet, contracts, prospectus or other applicable offer documents. Linking the instrument to better evidence does not expand those rights.

MiCA—the EU Markets in Crypto-Assets Regulation—does not apply to crypto-assets that qualify as financial instruments under MiFID II. A Transparent Token is designed as such an instrument, so the financial-markets regime is the relevant one. The classification is confirmed by the legal opinion and documents of each issuance.

The DLT Pilot Regime concerns authorised EU infrastructures for trading and settlement under defined conditions. Whether it is used depends on the venue, operator, instrument and approved structure. An Asset Token or blockchain anchor alone is not enough.

A better evidence chain does not remove market, tax, counterparty, custody, settlement or source-quality risk. Technology and smart-contract risk remain, as does dependence on the provider—mitigated by export and continuity arrangements, not removed. An investor must use the approved risk disclosures and perform the legal, tax, financial and technical review appropriate to the instrument and its own situation.

The word does not mean that everyone sees everything. It describes role-conditioned access to attributable, updateable evidence about the underlying asset. That connection can continue through the instrument's lifecycle, subject to the approved disclosure model and responsibilities.

It is a hybrid public/private DLT (distributed ledger technology, a more general term: the single ledger structure is actually a graph even if it possesses a simple chain as a backbone). The data lives in private, on-demand ledgers inside a private network — giving the privacy and performance of a private system — while a cryptographic trace of every ledger's history is recorded daily on a public blockchain, making every ledger tamper-evident and publicly verifiable like on a public chain. The data itself never touches the public chain.

Developed from scratch. Traent started by evaluating existing private blockchains (Hyperledger Fabric in particular) and found that all of them — to varying degrees — suffer high operating costs, low scalability, and trade-offs that often compromise security. The technology was conceived for managing business processes, not cryptocurrencies, so Traent dropped the conventional operating principles that only make sense for crypto and designed a new approach around the data properties actually needed.

Private and consortium blockchains keep essentially the same technology as public chains, just with fewer nodes — which limits performance and often undermines security — and they fail external auditability: participants can collude and rewrite history right before an auditor or a new node joins, undetectably. Traent's design differs at the root: consensus is not based on replicating the ledger across nodes but on cryptographic proofs, ledgers are created on demand per datum or per process, public notarization makes histories externally auditable, and data can be selectively erased (GDPR) without breaking verifiability.

No. There is no cryptocurrency, no token, no gas, and no mining anywhere in the platform. The daily notarization on the public chain is a plain transaction executed by Traent's Notary service — clients never need to touch crypto. Transparent Token and Asset Token instead live on a standard blockchain, with cryptocurrencies and gas involved.

The verification side is open source, deliberately: the Viewer web application that renders and verifies ledger exports (Apache-2.0, github.com/traent/viewer) and the C# library that parses the ledger data format (github.com/traent/ledger-dotnet). Open-sourcing the verifier is what makes verification genuinely independent of Traent; the audit-proof verification algorithm is also published in a scientific article. The platform's backend services are proprietary (and patented).

Consensus is based on cryptography instead of replication — replication being the root of the cost and performance problems of traditional blockchains. Every extension of a ledger is accompanied by Merkle consistency proofs, a proof type demonstrating that the history has only ever been appended to — no insertions, no reordering, no forks. On top of that, the daily public notarization anchors every ledger's history on a public blockchain: rewriting history — by anyone, Traent included — would break the chain of consistency proofs against the publicly recorded digests and become evident to any verifier.

From the public anchor. You don't have to trust the parties holding the data, nor Traent: anyone can take a ledger export and verify it against the cryptographic trace on the public blockchain — that the data is authentic, signed by its authors, and that the history never forked. The guarantee is cryptographic, not organizational.

Once a day, the Notary service writes on the public chain the digest of a verifiable data structure that tracks the entire ledger population. The notarization protocol uses one-way functions: only this cryptographic trace is published, and the Notary itself never even accesses ledger data — no business data ever reaches the public chain.

The notarization design is chain-agnostic: notarization uses no smart contracts and consumes no gas — it is a plain transaction carrying a digest — so the only requirement is that the chain supports arbitrary data in transactions. The chain used today is optimal on cost and latency (a large free note field, ~4-second blocks with immediate finality). The same writes can be directed to a different chain, to several chains simultaneously, or even to other trusted public storage; notarization on an additional chain (Base, an Ethereum L2) is planned.

Once every 24 hours, for the entire ledger population at once. Inside the private network blocks have instant, irreversible finality; for data exported before its notarization, exports include receipts signed by the platform's write-orchestration service, which provide signed accountability until the next daily notarization covers those blocks publicly.

Yes. Verification of an export needs only the export file, the public verification logic (the Viewer and parsing library are open source, and the verification algorithm is published in a peer-reviewed article), and the digest sequence on the public blockchain. None of that requires Traent's cooperation or existence.

Data lives in private ledgers within the private network — the platform is delivered as SaaS running on AWS — and access can be restricted down to a single node. The only thing ever published is the daily cryptographic digest, from which no data can be derived.

Per ledger: a node can keep a ledger entirely to itself, or share it with a selected group of nodes. The recommended pattern is one ledger per piece of data worth segregating (per product, per process instance, per contract). Within a ledger, disclosure is granular down to individual encrypted data fragments, and each ledger's genesis policy block defines authors and permissions. Every block is signed, hence non-repudiable.

In the ledger format, every individual data element is padded and encrypted with its own distinct key, derived from the ledger's master key (libsodium sealed-box construction); when producing an export, one decides which decryption keys to include, and the master key is normally included only in personal backups.

At the moment we hold no security certifications. We are committed to obtaining SOC 2 — we know it is a requirement for enterprise clients — and with clients we are prepared to formalize that commitment contractually, as part of the engagement.

Yes — this is the founding idea of the technology. Whoever holds a ledger export can verify the data's provenance and integrity, and that the ledger has a single unforked history since its creation date, using as the only trust anchor the cryptographic trace on the public blockchain. No access to the private network, no Traent account, no trust in Traent.

Yes. Exports are selective at several levels: which ledgers to include, and which individual data fragments to include — the typical case being the redaction of personal data. Omissions are evident to the verifier (no covert redaction is possible) but do not compromise the verifiability of the included data. The same ledger can even feed multiple views — e.g. a public, essentials-only product passport next to a detailed owner's version — all auditable against the same public trace.

No. Exports are opened in the Viewer, a web application designed for non-technical users, mobile-first: drag-and-drop a file, open a link, or scan a QR code printed on a product. The Viewer verifies everything automatically in the browser before showing anything — in the pilot measurements a full verification took roughly 1–2 seconds — and technical users get an advanced Explorer exposing blocks, proofs, and keys.

Verification fails and the Viewer reports the detected issues instead of displaying the data. Legitimate redactions look different: they appear as explicit, evident omissions that leave the rest verifiable.

There is no fixed block time or size: every state transition gets its own block, appended with instant finality — a design that minimizes per-transaction latency instead of chasing a transactions-per-second figure, and supports blocks from kilobytes to gigabytes. It was designed to serve as the primary data layer of real-time, data-intensive applications.

Ledger creation is instant, requires no network reconfiguration, and the number is potentially unlimited — more than 12,000 ledgers are managed in production as of August 2026.

Clients never interact with the public chain. By design, notarization is a single daily transaction covering the entire ledger population — regardless of how many ledgers or writes there are — so public-chain fees are negligible and do not scale with usage. No gas, no smart contracts. (Traent blockchain notarization only — does not apply to tokenization.)

There is no mining and no proof-of-work anywhere, and no network-wide replication of data — the two main energy sinks of traditional blockchains; the public-chain footprint is one transaction per day.

Everything goes through APIs, publicly documented at docs.traent.com. A small subset — creating a project and writing/reading data streams — suffices to use the blockchain as an immutable, verifiable data-tracking system. Realized solutions have integrated with customers' SAP systems (e.g. in DPP projects), and an API abstraction layer (Nexum) is being built to make API-only adoption by external integrators even simpler.

The platform is delivered as SaaS on AWS. The node component (OrgNode) was designed to also be deployable on premises, and an on-premises deployment of the notarization service was analyzed for feasibility.

No — and this is a differentiator against consortium blockchains, where existing members could collude and rewrite history an instant before sharing it with a newcomer. With public notarization, a node gaining access to an existing ledger independently verifies that no fork occurred before its inclusion: onboarding is trust-free.

A full export (including the master key) serves as a personal backup: you keep your data, and it remains independently verifiable forever against the public-chain trace using the open-source, published verification logic — no Traent involvement needed.

The platform has its own smart-contract analogue, called Workflows: deterministic programs stored on the ledger that act as an application-level consensus — every participant executes them to validate every transaction — typically expressing a business process as a finite state machine (states, transitions, who may execute each, pre/post-conditions). Because they run only among the interested participants, they escape classic smart-contract limits: they can be large and computationally heavy, access all ledger data, and need no gas. They are described in the peer-reviewed publications and in the public web documentation. They are not meant for financial data or transferable tokens.

Yes, at two levels: each ledger's policy block defines authors and write policies, enforced when extensions are approved, and every block is author-signed (non-repudiable); on top, a Workflow can specify per-transition authorization and conditions for an agreed multi-party process.

Transferable tokens are deliberately out of the Hybrid DLT's scope — it is designed for business-process data, not financial primitives. Traent's approach, currently being explored in real estate: the token lives on a traditional public chain (Base, an Ethereum L2), while the asset's data lives in a linked Traent ledger, with protocols giving the token holder access to that data and independent verification of it through Traent's technology.

Yes: over 12,000 ledgers are managed in the production environment (August 2026). Production use cases include digital product passports and process tracking — automotive DPP, wine DPP, ESG reporting, fact-checking, trustworthy-AI process tracking (pilots, now ended) — a multi-year industrial client in pressurized gas cylinder systems, and the real-estate vertical, whose flagship product Legal Twin is deployed.

Yes: eight scientific papers, most of them peer-reviewed — IEEE conferences and workshops (WETICE, IEEE Blockchain, PerCom/BRAIN) and journals (Computer Communications, Procedia Structural Integrity) — developed with academic collaborators, notably the University of Pisa. They cover the model, the scalable notarization algorithm, the auditable-data-structure framework, the authenticated visualization, and the trustworthy-AI framework, including experimental evaluations.

Yes: 8 international patent families (Italian filings extended via PCT, published in 2023), covering among other things the notarization approach, selective data management on verifiable structures, concurrent-write handling, and relations between ledgers. The notarization technology — Traent's most differentiating asset — is patented and not available to the competition.

Four capabilities, delivered by a single AI system shared across the products: document classification; information extraction from documents; a chatbot with RAG over the customer's own data; and execution of predefined series of checks on data, producing reports. Being one system, every improvement cascades to all products.

Yes — that is its design. The chatbot is grounded through retrieval-augmented generation on two kinds of sources: live data served by the product's backend API, and the organization's documents, processed into a vector database and queried at answer time. Answers are grounded in the organization's own content rather than the model's general knowledge.

The agents use frontier LLMs via API — currently OpenAI and Anthropic models. The integration of further providers is planned.

No. The AI functions are built as a product-independent abstraction layer over the models, so a model or provider switch propagates to all products without rebuilding them; a dedicated AI R&D team devotes a large share of its effort precisely to keeping up with the field, and multi-provider integration is planned.

Several layers: answers and extractions are grounded in the customer's actual documents and backend data (RAG) rather than free generation; the report capability executes predefined series of checks, not open-ended reasoning; and in the real-estate vertical, classification and extraction are guided by an internally developed domain ontology encoding sector expertise. In parallel, Traent is exploring small specialized models for the classification/extraction pipelines, aiming among other things at more reliable confidence measures. Every agent execution is fully traced, so behavior is inspectable.

Yes. In the real-estate vertical product, human-in-the-loop review is part of the flow: users are shown the classification of the documents and the extracted data, together with a confidence estimate for the operation, and they can manually correct the results or explicitly accept them. The AI assists; the user stays in control of what is retained.

The blockchain gives AI what it usually lacks: verifiable accountability. In the trustworthy-AI framework, every inference and the data lineage behind it are recorded on a ledger and publicly notarized, yielding certified inferences that an external party can audit — an approach validated in peer-reviewed papers, applied in a production process-tracking pilot (with model weights and code stored in the ledger), and proposed for critical-infrastructure monitoring.

In principle it is a quick activity. When moving to a different domain, the real work is collecting a sufficient number of examples, so that we can set up systems to measure the precision of classification and extraction on that domain — we don't ship what we can't measure. From our real-estate experience: a change of language is not in itself a problem; the more demanding and costly part is adapting the domain ontology to a different legal and regulatory system.

The products do not rely on training proprietary large models: they use frontier LLMs orchestrated as agents, with the domain knowledge injected through retrieval (RAG) and through an internally developed domain ontology — in real estate, a substantial structure of document categories, key information, per-building-typology specializations, check parameters and legal references, built by Traent's sector experts. Small specialized models for classification/extraction are being explored as complementary routes with different cost/precision trade-offs.

That is exactly Traent's approach in the real-estate vertical: months of sector-expert knowledge encoded into an ontology that the agents use for classification, extraction, checks, scoring and reports — and it is considered the vertical's main competitive advantage, since a generic frontier model is not a sector expert. Classic formal ontologies are additionally being explored as a further structure for domain knowledge. The same approach can be the template for encoding a client's domain expertise.