BLOCKCHAIN & WEB3 DEVELOPMENT

Your business logic.In dedicated blockchain applications.

At ENOR, we develop smart contracts, applications and blockchain integrations for processes that need shared rules and verifiable actions. We start from the real need to define the architecture and how it will be used.

Delivery ledger · illustrative appIllustrative view

Action request

Confirm delivery of shipment #A-1042

Sending party
Producer
Receiving party
Distributor
Document
Delivery note

Approval

  • Operator · Producer
  • Checker · Distributor

Transaction status

Pending

Waiting for the second party’s approval.

History

  • Shipment #A-1041Confirmed
  • Shipment #A-1040Failed

Verification reference

0x7f3a…c21e

  • Smart contracts
  • Applications and integrations
  • Testing and action control

INTRODUCTION

Blockchain adds value when it solves a concrete need.

Some processes involve several organisations that need to share information and verify actions under common rules. In those cases, blockchain can be part of the solution.

At ENOR, we assess users, data control, responsibilities and costs before development. We define what should be recorded on the network, what should stay in business systems and how the parts connect.

Blockchain doesn’t remove the need for trust, administration or agreements between parties. The analysis determines whether it is needed, or whether a traditional system is enough.

WHEN IT CAN BE USED

A shared ledger, when parties need to verify it.

Benefits are stated per case: traceable changes, verified actions, shared rules, defined automation and integration options.

  • Shared ledgers between organisations

    Several parties write and read under rules.

  • Process traceability

    A step-by-step history of changes.

  • Document verification

    Checking whether a document was altered.

  • Digital asset management

    Creation and transfer under rules.

  • Executable rules

    Conditions programmed into contracts.

  • Applications on existing networks

    Interfaces and integrations with public networks.

We don’t promise that every project becomes cheaper, faster or more private with blockchain.

CONSULTING AND ARCHITECTURE

First, we determine whether blockchain is the right choice.

We analyse the problem, the parties, the trust model, write and read control, privacy, volume, costs, integrations, governance, requirements for correction or deletion and how recovery works.

We compare as needed

  • Traditional database
  • Audit log
  • Digital signatures
  • Blockchain network

The result: a clear project scope and a reasoned technical proposal. Using blockchain doesn’t bring decentralisation by itself.

Is blockchain needed?Illustrative view

The best-fitting approach

  • Traditional database

    One operator, data that changes and is deleted.

  • Audit log

    A history of changes within one system.

  • Digital signatures

    Proof of origin without a shared network.

  • Blockchain network

    Several parties, shared rules, mutual verification.

An orientation aid; the decision is made after a full analysis.

Tick the statements that apply to your project and see which approach fits best.

SMART CONTRACTS

Programmed rules, with defined responsibilities.

We develop smart contracts that implement the project’s defined logic. We make clear who can act, which conditions are checked and what happens when an action fails.

  • Specification
  • Roles
  • Limits
  • States
  • Events
  • Error handling
  • Testing
  • Upgrade strategy when required
  • Privilege management
Delivery contract
Illustrative view

States

  1. Created
  2. Awaiting approval
  3. Approved
  4. Executed
  5. Rejected

Action

Pick an action.

Changing rules needs an upgrade mechanism decided before launch.

Pick a role and an action to see what is allowed and what is recorded.

A smart contract is code; it isn’t automatically a legal contract. Data and actions off the network need the relevant integrations.

We don’t promise risk-free execution or bug-free code.

DAPPS AND WEB3

An understandable experience on top of technical processes.

Web and mobile interfaces that connect to the wallet, check the network, prepare the action, ask for the signature and track status through to history. Users should understand what they are approving.

  • Web and mobile interfaces
  • Wallet connection
  • Network selection
  • Reading data
  • Preparing the action
  • Signing
  • Sending
  • Status tracking
  • History

We also handle

  • Wrong network
  • Action rejected by the user
  • Insufficient balance for the fee
  • Pending transaction
  • Failure
  • Account change
  • Wallet disconnection
Simulation · no real wallet, no fundsIllustrative view
  1. 1Connecting the walletIdentification: the app sees the address, not the keys.
  2. 2Checking the network and actionNetwork, amount and fee are shown clearly.
  3. 3SigningThe user sees what they approve and decides.

Four different actions

  • IdentificationLinking the address
  • Message signingNo transfer
  • AuthorisationPermission for a contract
  • TransferMoving an asset

Pick a scenario and step through it. No real wallet is used and nothing is sent.

ENTERPRISE SOLUTIONS

Shared processes between organisations.

Permissioned networks, organisation roles, write rules, process ledgers, ERP and CRM integrations, documents, reports and participant management.

We define

  • Who runs the network
  • Who adds participants
  • Who changes the rules
  • Who can access information
  • How incidents are handled

“Private”, “public” or “hybrid” are not security guarantees; the choice depends on the concrete architecture.

Permissioned network governanceIllustrative view
OrganisationWrites eventsReadsAdds participantsChanges rules
——
——
——
—

Records production events; doesn’t add participants.

Pick an organisation to see its rights and responsibilities.

DIGITAL WALLETS

Integration and management to suit the usage model.

We distinguish integrating existing wallets from building a wallet interface, and keys held by the user from keys held by an operator or provider.

The user holds the keys

Self-custody

The user controls the keys and recovery phrase; the application can’t recover them if they are lost.

  • Accounts and networks
  • Assets and history
  • Fees and approvals
  • Address checks
The operator holds the keys

Operator custody

An operator or provider stores the keys; this needs defined processes, roles and responsibilities, often legal requirements too.

  • Roles and approvals
  • Recovery flows
  • Transfer limits
  • Action auditing

We never ask for recovery phrases or private keys in public forms.

We don’t promise fund recovery when the architecture doesn’t allow it. Custody and transfer of assets need a separate technical and operating-model analysis.

TOKENISATION AND NFTS

Digital representation with explained rights.

Depending on the project: asset model, creation rules, roles, transfers, metadata, restrictions, integrations and administration. For NFT marketplaces: catalogue, offers or auctions, wallets, fees, status and reporting.

A token is distinct from any legal right linked to it. We don’t promise liquidity, investment value, price growth, automatic transfer of copyright or automatic proof of physical authenticity. Legal requirements are assessed by asset, market and how it is offered.

Asset modelIllustrative view

The token

A certified share of a production batch

Created by
The authorised issuer
Transferred
Only between verified accounts
Restriction
No transfer after expiry

The linked right

Ownership of the physical shipment

The legal link is defined in the agreement, not by the token itself.

Rules and roles

  • Creation only by the issuer
  • Transfer with approval
  • Revocation by the administrator
  • Metadata fixed after creation

TRACEABILITY AND VERIFICATION

Follow the records and the links between them.

Supply-chain events, document references, certificates from authorised parties, process status, delivery history and links to IoT devices. For each event we define the source, who records it, how it is verified, what stays off-chain and how it links to the physical object.

Supply chain · exampleIllustrative view
Source
Lab report
Verification
Hash of the report
Off-chain
The full PDF report
Reference
0x8e4…b7d

A blockchain record doesn’t guarantee the original information is correct; traceability isn’t live monitoring without the matching source.

Pick an event to see its source, verification and what stays off-chain.

IDENTITY AND DOCUMENTS

Verification without sharing more data than needed.

Document origin checks, digital credentials, links to identity providers, validity status, revocation and issuer and verifier roles.

  • Document origin
  • Digital credentials
  • Identity providers
  • Validity status
  • Revocation
  • Issuer and verifier roles

We don’t write personal data or sensitive documents directly to a public network by default; even references and hashes may need a privacy assessment. We don’t promise to eliminate identity fraud.

Certificate verificationIllustrative view

Pick the document

Verification checks the reference and status; the document and personal data stay off-chain.

Verify a document: valid, revoked or unknown.

DEFI AND EXCHANGE PLATFORMS

Financial projects with special requirements.

Protocol integrations, exchange interfaces, liquidity, lending, staking and asset management are treated as a specialised field. We present them as projects that need assessment, not as a ready-made offer.

Before a proposal we need

  • Operating model
  • Economic risk
  • Dependencies
  • Price sources
  • Privileges
  • Testing
  • Assessment of legal requirements
  • Independent review where appropriate

We don’t promise profits, safe returns, liquidity or funds protected from every risk. A KYC/AML integration doesn’t bring licensing by itself.

INTEGRATIONS

Blockchain as part of the business system.

Connections to ERP, CRM, mobile apps, identity, documents, IoT, payments, analytics and off-chain data sources, through APIs, events, indexing, retries, deduplication, reconciliation, history and monitoring.

  • ERP
  • CRM
  • Mobile apps
  • Identity
  • Documents
  • IoT
  • Payments
  • Analytics

We distinguish the on-chain ledger from data indexed in the application. Not every network has the same confirmation and finality model.

Illustrative view
  1. Network

    Contract events

  2. Indexer

    Reads and stores events

  3. API

    Provides data to systems

  4. ERP / CRM

    Updates the processes

What happens

The event is indexed and passed to the ERP.

How it’s handled

Automatic reconciliation with the order.

Indexed data is a copy for the application; the source of truth remains the on-chain ledger.

Pick a case: a late event, a duplicate, or one awaiting finality.

NETWORKS AND TECHNOLOGIES

The platform is chosen by requirements.

We assess the network for the project, not by popularity.

  • Participation model

    Public or permissioned.

  • Privacy

    Who sees what.

  • Finality

    When an action counts as final.

  • Fees

    Cost per action and volatility.

  • Volume

    How many actions are expected.

  • Tooling

    Languages, libraries and testing.

  • Administration

    Who runs the nodes.

  • Maintenance and dependencies

    Updates and external services.

Names such as Ethereum, other EVM networks, Solana or Hyperledger Fabric are mentioned only as context after checking current official documentation; they don’t imply partnership and we don’t use logos as proof.

Building a new network from scratch isn’t a standard module.

SECURITY AND TESTING

Security needs specification, testing and operational control.

Depending on the project: threat modelling, code review, functional tests, authorisation tests, boundary and exception tests, property tests, automated analysis, secrets management, privilege control and monitoring.

Unauthorised actionIllustrative view

How it’s tested

Calls from roles without the right.

Control

Role checks on every function

Internal testing, not an independent audit. A third-party audit is defined separately.

We don’t call internal testing an “independent audit”. When a third-party audit is required, we define the provider, scope and how findings are handled; even an audit doesn’t guarantee the absence of vulnerabilities.

PRIVACY AND GOVERNANCE

We clarify data and responsibilities before launch.

We define what is public, what is private and what is stored off-chain; who controls keys and configuration; how upgrades happen, how incidents are handled, what can be recovered and how operation ends or is handed over.

  • Public and private
  • Off-chain
  • Key control
  • Configuration changes
  • Upgrades
  • Incidents
  • Recovery
  • Ending or handing over operation

We don’t promise deletion of data from an immutable public ledger. Every legal statement is checked against current official sources for the project’s jurisdiction.

Illustrative view
  • Document hashReference only, after a privacy assessment.On-chain
  • Full documentStored in the business system.Off-chain
  • Customer nameNot recorded on the network.Private
  • Process statusVisible to everyone.On-chain
  • Agreement pricePrivate; off the public network.Private

An example decision; final placement is set after privacy and legal analysis.

Switch the network type to see where each piece of data goes.

PROCESS

From the use caseto a verified solution.

For technical uncertainty we can start with a PoC; for a new product we define an MVP. Timelines and costs are set after the analysis.

01

Analysis

We understand the problem, the parties and the trust model.

02

Feasibility

We compare approaches and decide whether blockchain is needed.

03

Architecture and prototype

We define the network, data, roles and experience.

04

Development

We build the contracts, application and integrations.

05

Testing and review

We check logic, authorisations and critical scenarios.

06

Controlled launch

We plan the environment, privileges and checks.

07

Monitoring and maintenance

We track events and changes as agreed.

What needs to be verified or automated?

Discuss your project
Network fees and external services are set separately.

WHY ENOR

Development that starts from the process, not from promises.

We don’t invent projects, clients, certifications, partnerships, years of blockchain experience or financial results.

  1. 01Analysis of the real need
  2. 02Reasoned architecture
  3. 03Understandable interfaces
  4. 04Controlled roles and actions
  5. 05Documented integrations
  6. 06Testing and phased delivery

FAQ

Frequently asked questions.

What needs to be verified or automated in your project?

Tell us about the use case and the parties involved. We’ll determine whether blockchain is the right approach and what the development steps are.


Never send private keys, recovery phrases, credentials or crypto deposits.

What our clients say

5.0
A
Arben Hoxha, CEO

Sample Logistics Co.

“They translated complex technical concepts into clear decisions for our team.”