About DVOLD
Information should not become detached from the asset it describes.
DVOLD began with a practical question: how do you keep purchase evidence, provenance, validation and relevant history connected to the same product or object? That question became a platform that helps people and organisations collaborate around auditable asset data.
Developed from a concrete problem. Designed as scalable infrastructure.
Evidence, asset and history
Separate records
- Purchase receipt
- Certificate
Traceable history
- Issuance
- Maintenance
- Validation
- Transfer
The reason
Evidence retains value when its context remains intact.
Each record may be correct on its own. The connection between them is easily lost when a product changes ownership, moves to another organisation or remains in use for many years.
DVOLD was created around the belief that relevant information should be able to remain connected to the asset. Not as one unrestricted record that everybody can access, but as an auditable structure in which provenance, role, status and history remain clear.
Where information ends up today
- Purchase receiptInbox
- CertificateFolder
- MaintenanceService provider
- AppraisalExpert
- PolicyInsurer
The goal is not to collect more data. It is to keep relevant data useful, traceable and selectively shareable.
From purchase evidence to an asset platform
A practical question became a broader infrastructure question.
DVOLD emerged from practical questions around purchase evidence, supporting records, authentication and validation.
At first the question appeared narrow: how can purchase evidence remain useful and auditable over time? Further development showed that the same challenge extends much further: relevant information can easily become detached from the product, object or document it describes.
A product has more than a purchase moment. It accumulates product data, ownership, warranty, maintenance, inspections, claims, certificates, components and transfers. Different parties contribute to that history through different roles.
That broader question developed into a platform where digital asset identities, evidence, roles, events and lifecycle data can remain connected to the same traceable history.
From evidence to asset context
- 01
The evidence
Purchase receipts and documents should remain accessible and useful.
- 02
The control
Users should be able to see where information came from and which party issued or validated it.
- 03
The asset
Information becomes more meaningful when it is connected to the product, object or document it describes.
- 04
The lifecycle
Maintenance, transfer, inspection and other events should remain part of the same traceable history.
- 05
The platform
Organisations and consumers need different interfaces, but can use the same trust model.
What we are working towards
Asset data should move without losing its provenance.
Products and objects increasingly move between people, organisations, systems and applications. The associated information often remains behind in the system where it was first recorded.
We believe that a digital asset identity can provide a shared anchor. Evidence, roles, events, ownership and relationships can be built around that identity under controlled conditions.
This does not make every contribution automatically true or legally decisive. It does make visible who added something, who issued it, which information was validated and how the history developed.
The asset is central
Information is connected to the product, object, document or component it describes.
Trust is visible
Added, Issued and Validated remain separate statuses with identifiable provenance and roles.
Access is selective
A party receives only the information and permissions required for its action.
History remains traceable
Relevant events and corrections do not silently disappear from the timeline.
Existing systems may remain in control
DVOLD does not need to replace operational systems to add continuity and context.
Technology remains adaptable
DVOLD is multichain and is not fixed to one blockchain or one technical configuration.
Our development principles
First understand what needs to become auditable. Then decide what to build.
DVOLD is not being developed as a collection of features that must be applied in the same way everywhere. Each application has its own assets, roles, data, risks and legal conditions.
That is why we begin with the actual situation.
- Practice before technology
We start with the action that currently creates disconnected information, repetition or uncertainty.
- Clear responsibilities
We define who adds, issues, validates, corrects, manages or transfers information.
- No false certainty
We do not present information as independently validated when only the source or issuer is known.
- Privacy by design
Personal data is never stored on-chain. Access and data sharing are configured around role and purpose.
- Validate in phases
A pilot should test process, data, roles and responsibility before an application is scaled.
- Honest product status
Technical capabilities, integrations and legal effects are presented as available only when the relevant scope has been sufficiently confirmed.
The team
Strategy, technology and business development around one product vision.
DVOLD is developed by a team with distinct responsibilities. The roles are intentionally separated, while the most important product decisions are assessed together.
Almansio Figueiredo Soares
Chief Strategy Officer · CSO
Almansio safeguards the strategic direction, positioning and alignment between product, market and organisation.
He translates complex technology into a clear proposition, structures the information and product architecture and ensures that new applications remain aligned with the wider DVOLD vision.
Focus areas
- Strategy and positioning
- Product and information architecture
- Brand, communication and website
- Priorities and project structure
- Translating technical capabilities into market value
Hicham Batou
Chief Technology Officer · CTO
Hicham is responsible for the technical architecture and for translating functional requirements into an executable and scalable platform.
He assesses data models, roles, validation logic, integrations and the technical operation of the registration layer. He also protects the boundary between what is conceptually desirable and what can be built responsibly.
Focus areas
- Technical architecture
- Platform and integration design
- Data integrity and registration logic
- Security and technical access boundaries
- Feasibility, phasing and implementation
Iwan Arts
Chief Business Officer · CBO
Iwan connects DVOLD to concrete market needs, operational processes and potential collaborations.
He brings practical use cases and market needs into the product process and helps determine where DVOLD can create demonstrable value for users and organisations.
Focus areas
- Business development
- Market and partner relationships
- Practical applications
- Customer and process needs
- Commercial validation and collaboration
From question to application
An application is strong only when market, product and technology solve the same problem.
- 01
The practical question
A user, organisation or partner identifies a situation in which evidence, data or responsibility is fragmented.
- 02
The product decision
The team determines which asset, roles, events and information genuinely need to be central.
- 03
The technical assessment
The required operation is assessed for feasibility, security, data distribution and integration.
- 04
Validation
A defined pilot tests user experience, operational performance and responsibilities.
- 05
Expansion
Additional processes, roles or systems are introduced only after the relevant criteria have been confirmed.
This prevents a technically possible feature from being presented as a solution before its practical and operational value has been demonstrated.
Our choices
Credibility does not come from the biggest claim, but from the right boundary.
Auditable rather than absolute
DVOLD makes provenance, role, status and history visible. The platform does not independently guarantee the physical authenticity of every item or the legal validity of every document.
Collaboration without unrestricted access
Parties can contribute through a defined role without automatically receiving the complete record.
Corrections without hidden replacement
Errors can be corrected while previous values and relevant events remain traceable.
Technical flexibility without dependency
DVOLD is multichain and does not need to be fixed to one blockchain, provider or system category.
Development without overclaiming
We distinguish between confirmed platform principles, features configured per implementation and elements that still require validation.
A shared exploration
Strong collaborations start with a clearly defined problem.
We speak with organisations that want to connect asset data, evidence, roles and history more effectively within existing processes.
This may begin with a consumer experience, an issuance or validation process, a service history, a transfer or an application in which several organisations collaborate around the same asset.
The first step is not a generic product demonstration. Together, we identify:
- Which asset or entity is central.
- Which information is currently fragmented.
- Which parties contribute.
- Which status and review are required.
- Which systems retain their existing roles.
- Which functional and technical questions need to be answered first.
FAQ
Questions that come up often.
8 questions about the team, how it began, statuses, authenticity, technology and product status.
Who is building DVOLD?
DVOLD is being developed by Almansio Figueiredo Soares, Hicham Batou and Iwan Arts. They combine strategy, technical architecture and business development.
How did the idea begin?
DVOLD emerged from practical questions around purchase evidence, supporting records, authentication and validation. Further development showed that the same need extends further: information, roles and events must also remain traceably connected to the same asset and history later on.
Is DVOLD only a consumer application?
No. DVOLD provides a consumer experience and a platform foundation for organisations and public-sector parties.
Why are Added, Issued and Validated separate statuses?
Information from a user, a known issuer and an independent validator does not carry the same evidential weight. DVOLD makes that distinction visible.
Does DVOLD guarantee authenticity?
DVOLD can make provenance, issuance, validation and history visible. The platform does not independently guarantee the physical authenticity of every item.
Is DVOLD tied to one blockchain?
No. DVOLD is multichain. The technical configuration may vary by application.
Does DVOLD work only with new systems?
No. Existing systems may retain their operational roles. DVOLD can connect selected data and events around the same asset.
Is the complete platform already available?
The platform principles and product direction are confirmed. Exact technical, legal and commercial scope is established for each application and implementation phase.
Tell us where evidence, data or history currently becomes disconnected.
We begin with the actual situation and then determine which roles, information and DVOLD capabilities are required.