Freight Trust & Clearing Omnibus

• Freight Trust & Clearing Omnibus
• Overview
• Rulebook Notice
• Overview
• Freight Trust Network Overview
  • Protocol
• Nodes and Nodlets
  • Nodes
  • Nodlet
  • Sub Node Classes
• Threshold Utility Level
• Categories for Network Operations
• End-market fundamentals
  • Governance

Resources

Quick System Scope

This is what it takes for a transaction to occur

• UserRoles
• UserTypes
• Container
• ContainerCodes (STIFL)
• Conveyance
• Non-negotiable
  • Bill of Lading
  • Warehouse Receipt
• Negotiable
  • Bill of Lading
  • Warehouse Receipt
• Transactions
• Electronic Data Interchange
  • X12
  • 4010 204 Motor Carrier Shipment Information 210 Freight Details and Invoice 211 Motor Carrier Bill of Lading 214 Shipment Status Message 997 Functional Acknowledgement
    • Additional Transactions Supported
• Protocol
• AS2 Protocol
• Concenus Protocol
• MFT Protocol
• PKI
  • x.509
  • ECDSA

• Maidenlane

• Network Design

• Ecosystem
• Protocol
• Pricing Precedence
• Pricing Benchmark

Overview

Guide to the documentation is as follows:
    * Category *an informal name given to a section or collection of sections*. 
       - Section *a formal name given to a specific part of the* `omnibus`. 
           + Sub-Section *a formal name given to a specific part of a* `section`. 

• Operations

• Corporate …- Pricing Benchmark

  • Pricing Precedence
  • Transaction Pricing
  • Incident Response Plan
  • Software Defects
  • Business Continuity

• Explainations

• Concepts

  • Mechanics & Dogma: This can be thought of as an abbreviated "informal academic paper"

• Legal

• Rulebook

  • General: Information on the legal paramters that constitute how behavior is regulated on-chain.

• Technical

• Blockchain

  • Token Overview: Information on the $EDI Token and its utility
  • Staking: Information on how Staking Pools
  • Network: Information on "master nodes" and the "pools" for nodes

• EDI (X12)

• Transactions with available Parsing and Mapping Support
• Available Transactions with just Parsing
• EDI General
• All supported Transactions
• Schema Registry

Rulebook Notice

Overview

• Lower transaction cost to drive evolution in markets
• Look for fragmented markets as an opportunity to seek for efficiencies
• Pass on to the customer the savings introduced by efficiencies
• Innovate pricing thanks to marketplace mechanism and data
• Build mechanisms that support suppliers of all size
• Invest in creating a mechanism that brings the best to the top (i.e. rate of failure)
• Invest in mechanisms for empowerment, augmenting workers potential Read more …

• Being able to communicate and persist events.
• Being able to take direct action on events.
• Processing event streams to derive real time insight/intelligence.
• Providing communication for event driven microservices.

Freight Trust Network Overview

We adopt a “cryptoasset” pricing model, evaluate our current token model, and propose several changes in order to maximize value accrual as the network opens for public (i.e. business) usage. Much of this work is based on sources found at the end, and we would like to thank everyone who offered their critiques and thoughts on the subject.

Examining the “bifurcated” token model (having 2 tokens: a transactional token (network native) and a “system” token (erc-20) is shown to be a better model than a traditional singular token model.

Protocol

On Protocols

> "Protocols encode the rules of engagement that coordinate the
> exchange of a service between a global supplier and global
> consumer."
> 
> —  Chris Burniske Protocols As Minimally Extractive Coordinators

Protocols provide structure for businesses, but are not businesses themselves; they are systems of logic that coordinate exchange between suppliers (businesses) and consumers of a service. As coordinators of exchange, protocols should be minimally extractive, whereas businesses are incentivized to be maximally extractive (that’s profit, and a business is valued as a multiple of its profit). The ERC-20 token, $EDI, acts as a right to receive the native network asset, xEDI on demand. xEDI does not act as a right to receive any other asset, instead, it grants the right to transact on the network-based upon market conditions and pricing. This does not preclude a trading mechanism from existing: we simply enforce a one-way mechanism for EDI to xEDI.

Nodes and Nodlets

Nodes

Masternodes == Nodes. All nodes are technically the same. The classifications below are more specifically slots. Nodes are rotated into different slot positions over an epoch. An epoch is defined in terms of checkpoint increment authority: concensus signing node validator: failover

Nodlet

There are 4 maine classes of nodes. A master-node and the 3 nodelets

Sub Node Classes

• besu-tx: Handling of local transaction pool.
• besu-sync: Handling of blockchain synchronisation through Ethereum P2P network.
• besu-query: Handling of database queries.

Threshold Utility Level

The ERC-20 token, $EDI, can enable access to the network level operator system, commonly referred to as "master nodes". This is both a network and a legal operation as operators are part of a limited partnership that is compensated from Freight Trust Inc.

Network operation is distributed amongst “Master Nodes”. An amount of $EDI is required, x, in order to be able to be eligible for hosting part of the main network.

Categories for Network Operations

[
    {"Category":"Nodes","Item":"Authority,Validator,Failover"},
    {"Category":"Nodlet","Item":"query,sync,transaction"},
    {"Category":"Staking","Item":"Operator,Pool"}
]

End-market fundamentals

In our use case, we assume that the platform will accrue transaction volumes at a consistent dollar rate per user transaction set (e.g. EDI transaction to a trading partner). This transaction volume would likely be composed of an end-user directly paying for the transaction on a per kilobyte basis.

Value flows being distributed in the native cryptoasset requires an exogenous assumption to form a base of value, and even then, the supply-side’s assessment of the value they’re receiving can be unpredictable given the native asset’s volatility. We can make the assumption that at equilibrium the service should be 1/10^th the cost of a service provisioned by a company comparable (e.g., storage at 1/10^th the cost of AWS), as only networks that are more efficient than companies will be able to get demand-sides to make the leap. The cost of the service can then be pinpointed, the units of the service consumed can be projected, and the product of the two is the value stream flowing to the supply-side.

That value stream is what the cryptocapital has claim to, and so the capital asset component of value can be assessed. The “outside” anchor is the cost of comparable services that the cryptonetwork (freight trust network) will be competing with, though trouble remains if the native cryptoasset is too volatile, as that volatility influences the supply-sides’ perception of what they’re getting paid. Freight Trust, Inc includes a few “legacy” mechanisms to address this point, such as payment to node operators in fiat, thus establishing a fixed cost floor.

Governance

Governance mechanisms in general should: 1) Attract a willing supply-side that produces the resource (node operators, stakeholders, community et al)

2) Connect that resource to a demand-side that values and is willing to pay for the resource (businesses)

3) It creates an open layer of access to the underlying resource for distributors that want to build the last mile to the consumer. (Freight Trust Corporate) As of right now, no formal governance mechanism besides the informal RFC process exists for EDI. We plan in the following days to formally propose a new governance mechanism based upon Dynamic Alignment. We have included a graphic to illustrate the idea behind it