If your DL Freight account is locked, please send an email to dlfreight.support@dltlabs.io to access your account.

An activation link is sent to your registered email address. Click on the activation link to access the DL Freight platform. Contact your organization's assigned representative/Admin to receive an activation link. NOTE: The activation link is valid for 48 hours.

[Including but not limited to login failures, successes, account lockouts, etc.]

Successful and unsuccessful login attempts trigger the application to capture details like the number of unsuccessful attempts, ID used for gaining access, Date and time, IP address, Region, and Account status (active, inactive, de-active, or locked). These details can be updated per the client's request and approval from the DLT Labs Security team.

[This query includes moving, adding, changing, and deleting user accounts.]

The operator account can administrate the user accounts under it. This account is the parent account and is under the client's access. The operator account can – change accesses – activate and deactivate users – and edit user details.

The platform supports authentication features such as Password Complexity, Password Re-Use, Session Timeout, Account Lockout, Password Reset, Multi-Factor, etc.

• Password length greater than four and less than 99.
• Password mandates lower case, upper case, number, and special characters.
• The last five passwords cannot be re-used.
• Session timeout is 30 seconds. The timeout duration can be changed per the client's requirement.
• Account lockout after five incorrect attempts.
• Password reset is allowed only through registered email addresses.

• It is password authentication for all the users using the UI for interaction and accessing the platform and is session cookie-based access.
• The same is the case for Mobile access.
• If the interaction is a backend application, it is based on OAuth. Essentially, we provide a ClientID & secret for each application to generate a token and interact with our APIs.

The user will have to hit the webhook "

The Digital signatures can be attached to the forms where required. After reviewing the required details, an entity receives an instance; the acceptance can be approved. On approval, the user's digital signature reviewing the details will be attached to the record and stored on the Digital Ledger.

If the user wants to revoke the approval, then the digital signature available on the records will no longer be valid. The condition for validation of the digital signature will involve approval of the details shared and the availability of the signature. If the latter is missing, the signature will not be considered an approval of the details.

The Fabric users and secrets are created at the user creation process initiated by the Platform Admin or Operator.

The platform will not allow any inaccurate information to be mined. It works and authenticates/authorizes strictly based on OIDC and OAuth2.0 protocol.

The consensus mechanism will ensure that the entered information has the consent of all the nodes.

Asset Category's name and description can be edited. The asset category cannot be deleted.

Find out more about Asset Categories.

The trigger information would be the events that will initiate the automation processes. Any data with a definite value or a range of values can cause an automated trigger in the platform. Information like names, phone numbers, and security numbers can be used to trigger automation in the platform.

The business workflow does not support circular dependency. If the system finds one, it will not allow the workflow to be saved.

A business workflow will end when it reaches the expiration date. You have another option of deactivating the business workflow if required.

Learn more about managing Business Workflows

Branching can be achieved using connectors. This is available at the time of workflow creation. How to create and configure a Business Workflow? – Let's find out!

Considering the client is concerned if there is maintenance access from specific countries.

There won't be any maintenance access as when the client buys the cloud storage, the cloud companies like AWS, etc., will ensure complete access to the client and the information stored within it.

DLT Platforms are well equipped, and the information is access controlled. This means the platform can be controlled by who can view and who cannot view the content/information. The information is available only to authorized personnel/groups as per the business requirement.

IAM = Identity Authentication Management.

DLT manages the platform, which manages the Operators, which manages the Participants. DLT follows strict authentication guidelines according to ODIC and OAuth 2.0 protocols. AWS IAM key or any cloud access and identity management have no linking to the roles and access of users on the platform.

Operators are the brains, the governing body of the platform. They configure the platform. Participants execute the workflow. For now, permissions are group-centric but eventually will be participant-centric. Operators determine what a participant can view and what they can edit, and operators also design and define the code chain on Fabric.

The DL platform supports Role-based access for various users. The access permissions are statically defined in the product for those fixed roles we support.

The chaincode in the fabric is entirely managed by the network admin. No other user has permission to deploy, install, or instantiate the chain code.

There are seven user roles associated with the DL Platform to meet the functional requirements. The associated user roles are:

1. Platform Administrator

• Platform Admin is authorized personnel from DLT Labs.
• Adds Operator from enterprise.
• Configures enterprise-specific requirements.
• Manages enterprise information.

2. Operator

• An assigned representative from within the enterprise or enterprise owner.
• Adding and configuring other user roles such as Participants and Monitors.
• Adding new asset profiles, categories, and workflows.
• Creating profile groups and assigning members and other fields to them.

3. Subordinate

• Subordinates and Operator Accounts have equal access to the platform. However, Subordinates are managed by their respective Operator.
   
  

4. Participant

• Participants are asset holders within an assigned workflow.
• View personal data, notifications, and modifications made on enterprise applications.
• Send/Receive/Reject workflow instances.
• Provide values to asset attributes concerning the groups and processes they belong to.

5. Data Operator

• Data Operators are entities within the enterprise that maintain information about the organization.
• View all Master Tables assigned by the operator.
• View/Add data/Download data from Master Tables.
• Basic profile functions.

6. Monitor

• A Monitor can be from within the enterprise, a contractor, or 3rd party representative.
• Has read-only access.
• Reviews transactions within an assigned workflow.
• The Monitor can flag or add comments in a workflow in case of any disputes.
• There are two types of monitors for DL Asset Track™, i.e., Internal Monitor and External Monitor.
• The internal monitor is assigned from within the enterprise and can be referred to as an Auditor.

To achieve HA (High Availability) on the DL Platform for DL services, follow the steps below on the architecture and monitoring front.

1. All the servers are connected to a scalable load-balanced cluster, and all the requests are directed to the available server nodes using the Round Robin Algorithm.
2. All the databases, message brokers, etc., run on a cluster to assure HA.
3. Real-time monitoring (health check) and failure detection are set on each node to send an alert to respective teams for appropriate action.

Currently, there is a logical separation of users done at the DL-Layer based on which tenant (operator) they belong to. For the ASIK layer, multi-tenancy is introduced. At present, all the users co-exist in a single space.

Branching can be achieved using connectors. This is available at the time of workflow creation.

The Byzantine Generals Problem describes the difficulty decentralized systems have in agreeing on a single truth. The Byzantine Generals Problem plagued money for millennia until the invention of Bitcoin. Bitcoin uses a Proof-of-Work mechanism and a blockchain to solve the Byzantine Generals Problem. Find out more about Byzantine General's Problem in this blog.

A vital component of the DL Platform is its modular design. The multi-layered architecture is interchangeable, allowing you to pick the functionality your organization needs and incorporate additional features and functionalities as your business evolves.

The platform can be arranged to suit:

• Tracking and tracing of tangible or digital assets.
• Business Workflow and supply chain
• Value transfer and exchange
• Contract enforcement and compliance
• Provenance and authentication
• Credentials and certification
• Records management
• Privacy & consent

Each module can function independently and seamlessly integrate back with each other through product configuration when needed.

Modern business network workflows are inherently complex. Whether it is the tendering of shipments to different carriers, resulting in different business rules, or tracking and tracing commodities shipped via different modalities (land/sea/air), maintaining accurate records of these transactions remains challenging.

Out of the box, though, DL Asset Track supports the ability to configure workflows with conditional, non-linear, and complex paths within a powerful and feature-rich enterprise admin console. It is defined by its unique ability to simplify complex business processes by reducing or altogether eliminating unnecessary steps. For example, leveraging smart contracts and master tables (i.e., contracted rates) can eliminate audit cycles as the platform enforces compliance with these contracts – all achieved with minimal code intervention through the enterprise admin console. Additionally, the console allows the user to define workflow attributes and business rules within tested, production-ready selectable validations.

The DLT platform is both industry and business case agnostic, i.e.; it’s not restricted to operating within the confines of specific verticals or proprietary technology. The platform's democratized accessibility works brilliantly across various sectors, from logistics and supply chain management to financial services and raw materials tracking.

We will give you a complete extract of all your data stored on the blockchain, which you can upload wherever you wish.

The callback can be configured from the participant's account. When you log in to the platform and go to the workflows, you will see two icons on the top right. One is for generating credentials and the other for a callback.

To receive updates from an external source, we have a set of exposed APIs. The external source can use those APIs and send the information to DL Asset Track.

To send updates to an external source, we have exposed the service node when configuring a workflow. This node has a POSTMAN look-alike configured within it. We can use this to send information to the external source by calling their APIs.

Explore the product documentation to configure callbacks and authentication.

A wide variety of integrators are available:

1. RESTful API's
2. Various system connectors (e.g., SAP, TMS Oracle, etc.)
3. EDI
4. IoT
5. Batch System Integration
6. Data Lake
7. Big Data
8. File Extract or Dump
9. Any BI or Reporting Tools

The data is written to state DB(in this case, Couch DB) based on events generated in the system. Every transaction produces an event and will thereby trigger data writes to state DB. The data write operations are done by a pre-configured service account (by the system) and don't have any direct access to the users.

The off-chain and on-chain information are determined at the time of final requirement gathering. We can confirm that all PII data will not be on-chain to comply with the regulations such as GDPR.

Here are the data storage criteria – Usually, critical and transaction-related data will be stored in the blockchain, and other business-related data will be processed at the DL Layer. Some of the following will help.

DL Layer:

• Master-data
• User info
• Intermediate Data for processing
• Configuration
• Event Audit Data (less critical)

On-Chain:

• Attributes
• Workflow
• IoT Data
• Transaction Audit Data

The following is the integration diagram which will give you the required information about DL Platform and its integration with 3rd party systems and devices.

DL Asset Track uses a completely distributed network topology where each VM is distributed across various data centers or zones.

All VMs are deployed using the Kubernetes technology. Therefore, the specification of the VMs is irrelevant. Recommend configuration values are stated below. The recommended values may change depending upon further discussions during the requirement phase.

Server Capacity Requirement (OD – Centos7.x/Amazon Linux):

2VM'S (DL Web Servers) – No. of Cores: 4, Memory: 8GB

2VM'S (ASIK Web Servers) – No. of Cores: 4, Memory: 8GB

2VM'S (IAM Auth Web Servers) – No. of Cores: 4, Memory: 8GB

3VM'S (MongoDB Servers) – No. of Cores: 8, Memory: 32GB

2VM'S (Postgres Servers) – No. of Cores: 4, Memory: 16GB

4VM'S (Zookeeper Kafka Servers) – No. of Cores: 8, Memory: 16GB

2VM'S (CA Servers) – No. of Cores: 8, Memory: 16GB

3VM'S (Orderer Servers) – No. of Cores: 8, Memory: 16GB

3VM'S (Peer Servers) – No. of Cores: 8, Memory: 16GB

3VM'S (CouchDb Servers) – No. of Cores: 8, Memory: 16GB

There are a series of steps taken to protect the data and remove the security concerns. These are steps as follows:

• All the Data at rest or in motion are encrypted. Every transaction to read or update the data needs to get signed by a certificate, and then that signature is verified by the blockchain.
• An immutable activity log is maintained for every transaction, ensuring no one can access the data without leaving a footprint.
• We allow the client to choose at the attribute level (smallest unit of data) if it can be shared or not, and if it can, then what type of operation can be performed on it.
• All these measures together make the data within the system extremely secure, but at the same time, it allows the client to share with partners securely. There is a layer just above the data, and there is no way this layer of security can be removed, edited, or played by anyone in the world, including the owner of the data.
• Smart contracts can be created and edited only by the platform's operators. These operators are people who can enter the platform after being correctly authenticated and authorized by OIDC and OAuth2.0 protocol.

The platform will not allow any inaccurate information to be mined. It works and authenticates/authorizes strictly based on OIDC and OAuth2.0 protocol.

The consensus mechanism will ensure that the entered information has the consent of all the nodes.

Authentication Layer where the protocols redirect users to enter their credentials with verifiable assertion.

- Channels allow for logical segregation of the blockchain where only permissioned users can see assigned data.

- Adding /removing participants from the network is more accessible and less costly, as they will be added through a centralized (and permission) administration panel.

- The platform captures all the activities and logs for the authorized participants to view.

- The authorized team can provide access to the blockchain explorer for audits and logging purposes.

Possible. But will be allowed after approval from DLT Labs security team.

Vulnerability disclosures will be provided to the client via email. These emails will be sent to the authorized email IDs provided by the client. The results will detail the vulnerability to the extent of how it was caught, what caused it, and the solution.

The DL Platform undergoes regular security checks. In case of any vulnerabilities are found, the security patches will be provided post thorough testing and checks, ensuring zero risks. DLT Labs will deploy the patches with the help of the client's security team with zero downtime as all deployments are containerized.

A checklist for securing and hardening the environment and platform will be provided with the updated test results and suggestions.

This checklist will compromise handling:-

-Management of Platform Access

- Minimizing external footprint

- Patch vulnerabilities

- Minimize the attack surface

- Restrict admin access

- Check on user access permissions

- Hardening and protecting credentials

- Backup Plans

- DR Management

•    It is basically, password authentication for all the users using the UI for interaction and accessing the platform and is session cookie-based access thereafter.

•    The same is the case for Mobile users.

•    If the interaction is a backend application, it is based on OAuth. Essentially, we provide a ClientID & secret for each application to generate a token and interact with our APIs.

Key area while creating and configuring a Business Workflow on DL Asset Track, the auth feature "provides secure identity authentication for all users of the proposed module".

The Digital signatures can be attached to the forms where required. After reviewing the details shared, a group receives an instance; then, the acceptance can be deemed approved. On approval, the user's digital signature reviewing the details will get attached to the record and get stored on the Digital Ledger.

If the user wants to revoke the approval, then the digital signature available on the records will no longer be valid. The condition for validation of the digital signature will involve approval of the details shared and the availability of the signature. If the latter is missing, the signature will not be considered an approval of the details.

Certificates can be verified by the unique transaction hash and or QR code which are just two separate forms of representation on the blockchain. The configuration on the platform allows the user to select any one of these options. Verification by transaction hash can be done via the public website, the authenticated state, and the mobile app. A mobile app can verify the QR code.

Certificates compromise of attributes. These attributes include the participant’s name, issue date, valid date, course name, and grade. In addition, several customized attributes can be added to a certificate. The certificate has an immutable representation on the blockchain, which is the basis for validating; however, all the attributes are not put on the blockchain due to protecting PII data. All non-PII attributes sit on the blockchain, whereas PII attributes are stored off-chain, and their representation (hash) gets stored on the blockchain to make it immutable.

All the data on-chain is signed & encrypted at rest or in motion by a certificate owned by the owner of the data, and there is no way anyone else can decrypt it. This is how the platform ensures all data on-chain are safe & secured.

As the data is stored and managed on the cloud, the responsibility will be with the client owning the cloud. Ideally, in this case, where it is the client's data, and the access is with the client, it is assumed to be the client company responsible for information leakage.

If this leakage happens from the system, it will leave a footstep behind as everything is captured on Blockchain and immutable.

You can check the audit trail using the portal or API's Comment & Activity Log feature.

Find out more in the Activities & Comments section on the product documentation page.

All the transactions occur over a permissioned and private blockchain network assigned/facilitated for the enterprise. And each of the transactions has a unique id that can be verified and accounted for within the network. Any changes or modifications are treated as transactions that cannot be erased or edited. Additionally, the blockchain network has an immutable ledger that stores the transaction record updating it simultaneously with all the peers/nodes in the network in the intervals of minutes. The concept of Byzantine’s General problem would be the best example of how the secure network works and is immune to tampering.

The unique transaction ID is available for each workflow instance on the DL Platform. Access the transaction ID by selecting the required business workflow. Identify the instance that you need to verify the transaction. Click on the View Details button of the workflow instance. From the details page, select the Blockchain/Platform Logs option. This window provides the details of all the transactions in the selected workflow instance.

The smart contract/chaincode version is controlled by ASIK.

Versions for product releases and patches are managed by the business and delivery management team from DLT Labs.

The platform is based on the core concept of the supply chain, where before exchanging any Asset, the organization must first carry out a handshake. Once the handshake is done, only then should an organization be able to send an Asset. The other organizations should be able to confirm that it has received the Asset. This is the basic principle of communication which says communication is always bidirectional. One-way communication will primarily result in a dispute. DL Asset Track ensures all the communication within the organization is always bidirectional.

Walmart collaborates with thousands of organizations to make sure all their stores have enough goods. Among all other collaborations, the one partnership which is the most important for Walmart is the one with carriers. The carriers are Walmart’s supply chain backbone. Therefore, they wanted to make sure carriers could have the best o the relationship with them; in other words, Walmart wanted to make sure carriers trusted them. In our view, there is no better technology than Blockchain to improve trust among organizations.

DL Asset Track is exceptionally flexible and can be changed anytime to meet new business needs. The system is designed to upgrade a Business Workflow, then make a copy of the Business Workflow, upgrade it, and replace it with the old Business Workflow. We have done it to make sure the owner of the Business Workflow doesn’t end up updating the live Business Workflow without notifying all the other Business Partners on the network. This behavior of the platform can be changed for a tenant, but it’s not recommended.

If a Quick Pay contract is agreed upon between Walmart and Carrier, then the Carrier information is communicated by Walmart to DL Freight. Within DL Freight, the carrier details are captured. When an invoice against the respective carrier is generated, the system ensures the following points with the help of smart contracts.

• Quick pay is enabled for the respective carrier.
• Applicable discounts and charges are applied to the invoice.
• The necessary information is passed on to the SAP for processing.

DL Freight can cater to Quick Pay options in multiple ways depending upon the business rules and contracts between two parties: Scenarios could be the following:

All invoices of a particular organization can be considered for Quick Pay.

Invoices ranging between specific monetary values can be considered for Quick Pay.

Invoices generated between specific dates of a month/cycle can be considered for Quick Pay. Likewise, there could be other options too.

Below is the snapshot of DL Freight with the Quick Pay option enabled against one of the carriers. These are not manually entered for every invoice but calculated by the platform based on smart contracts.

When editing an expression as an operator, the latter can see the child expressions on which the master expression is directly dependent. Also, in case of dependency of any expression on other expressions, which results in a deadlock, such circular dependencies are alerted by the system and prevent the operator from making such mistakes. Find out more about Expressions.

Select the required Business Workflow after successfully logging into the application. Upon selecting the required workflow, an instance/shipment listing page appears on the screen that contains all the shipments or workflow instances. On the listing page, you can search for a specific instance/shipment in the following ways:

• Search via unique instance number or loaded or shipment id – there is a generic search bar on the listing page where you can enter the unique id. More details
• Search instances using built-in filters – if the unique id is not available, you can sort various instances using built-in filters readily available on the listing page. More details
• Search instances using custom filters – The DL platform supports custom filters that you can define using various attributes and column values available on the listing page. More details

• The application doesn’t create an entry for a load for a carrier if the Hazmat indicator is blank. The system will not allow adding this load to the workflow.
• Since the load is not present in the system, no action is required from DLT Labs to cancel this load in the system.
• Loads present in the feed file cannot be canceled. In the subsequent feed, the system will again Activate those loads.
• Change the status of these loads to other than ACCEPT status, and then the feed will stop showing these loads, and then we can cancel them.

When a load ID is expected but doesn’t appear in the DL Freight portal, the most common cause is that it has not reached a status of “ACCEPT” in the Walmart TMS (WTMS).

The carriers must respond/revert to Walmart’s EDI 204 and EDI 990 in the tender process to ensure this.  Contact your Walmart representative and have them manually accept it in their TMS on your behalf.

You can raise a dispute on these, and Walmart will update their Toolkit.  DL Freight application will, in turn, receive the updated rate and automatically recalculate your invoice.

Explore how to raise disputes on DL Freight - Dispute Management

Carriers are heavily motivated to get on board with the platform as they get paid much faster by using the DL Asset Track Platform than using the old system.

Carriers are the peers.

The return on investment for Walmart has been enormous. An extremely conservative estimate is 10x ROI which would not have been possible without using blockchain. One of the main reasons is without trust in the system, no carriers would have agreed to put their data onto the platform.

The ROI calculation is both vital and complex. It is inter-departmental, which helps have departments aligned and committed but has comprehensive before and after information that requires working with each department. There are confidentiality concerns, so further review and discussion of savings/ROI and new revenue are under NDA only.

The goal was to configure a system that provided a much deeper level of insight into the retailer’s invoice, reconciliation, and payment processes. For this to be successful, we had to start at the very beginning, which meant an end-to-end audit of the interlinked processes of the enterprise. While this represented a lengthier approach, the result allowed us to configure a solution that tackled the major challenge head-on and meant that there were no surprises affecting future enhancements.

This end-to-end approach enabled us to:

• eliminate time-consuming aspects in existing processes.
• Simplify complex processes related to managing payment-related invoicing and disputes.
• Add improvements that would benefit both the enterprise and its vendors.
• Help surface financial leakage not previously detected.
• Implement further enhancements surfaced during the rigorous UAT (user acceptance testing) process.
   
  

The DL Platform has evolved in the following areas:

• Advanced reporting features support a greater level of report automation and scheduling.
• Multi-format file upload and data capture, including images, text, and CSV.
• Advanced record level versioning allows the application to capture more significant volumes of data faster.
• Advanced automation features are used as validators for complex processes.
• Further permission sets were introduced to allow the configuration of business workflows.
• More significant modifications are allowed during a running workflow, enabling easier reconciliation.
• The user onboarding process was further automated, allowing for a faster certification procedure.
• Business workflows can accommodate scenarios with multiple decision points.
• Multiple decision points were addressed with hyper-automation features reducing manual intervention to almost 2%.