Michael Zargham is the founder and CEO of BlockScience and has expertise in decentralized optimization, control theory, game theory and applied math. He discusses how blockchain technology uses a decentralized ledger, consensus protocol and community to coordinate interactions. Coordination can be done centrally through platforms or decentralized through protocols. Applications like ODEM use blockchain, identity, payments and AI to facilitate multi-party coordination by capturing commitments, finding feasible outcomes, validating rules and enforcing commitments. ODEM's marketplace coordinates educators, students and auxiliary providers for on-demand education programs.

1. Michael Zargham, PhD
@mzargham
COORDINATION MARKETS
CRYPTO-ECONOMICS AND THE APPLICATION LAYER

2. Speaker Bio
• Founder and CEO and BlockScience
• Contributor & Advisor, ODEM
• Contributor & Advisor, Sweetbridge
• Contributor, Mad Network
• Founder and Chief Scientist at 50X Ventures
• Former Director of Data Science and Architect of
Data & Decision Systems at Cross MediaWorks
• PhD in Systems Engineering, UPENN; studied
Decentralized Optimization and Decision Science
• Academic expertise in optimal and stochastic
Control Theory, Game Theory & Applied Math
• Quantitative Analyst and Decision Systems
Engineer since 2005.

3. Blockchain Technology
• Also called decentralized ledger technology (DLT)
• In general, a blockchain network is defined by:
• A data structure: the “ledger” but can be generalized, i.e. for the Ethereum network the data
structure is the state of the EVM
• A set of methods which operate on the data structure; in the simplest case this is a
transaction sending tokens from one address to another
• A consensus protocol: set of rules for agreeing on the true state of the data structure, based
on verifying the validity of transactions
• A community: the set of agents (human or machine) which are participating in the network;
lightweight clients may broadcast transactions but full nodes are required to participate in
validation process (consensus protocol)

4. 2-Party Coordination
Feasible
Agreements
My rules or
Requirements
Your rules or
Requirements
Agree upon
Coordinated outcome

5. Modes of Scaling Coordination
Centralized Authority Coordinates Peer to peer coordination
Local Nodes
Central Authority

6. Centralized Coordination Services
“Gig-economy” platform marketplaces
• Airbnb (host, guest)
• Uber (driver, rider)
• Taskrabbit (service provider, consumer)
“legacy” two sided markets
• Credit Cards (merchants, cardholders)
• Operating Systems (developers, end users)
• HMOs (Doctors, patients)
“Attention” platforms, Sharing and Social Media
• Twitter/Facebook (poster, reader)
• Youtube (uploader, viewer)
Centralized Authority Coordination
Central Authority
Note that while the economic activity may be decentralized the businesses and software enabling that activity are centralized

7. Decentralized Coordination Services
Protocol Level Decentralized services
• Distributed Hash Tables (DHT) - Bittorent
• Decentralized Ledgers - Bitcoin, etc
• Decentralized Virtual Machines - Ethereum
The Protocol Level is a set of tools for building
applications or even for building components for
more complex applications
• for example, Civic and uPort provide self
sovereign identity services built on top of the EVM
• IPFS provides secure decentralized file storage by
combining a Decentralized Ledger with DHT
Peer to peer coordination
Local Nodes

8. Coordination Applications
Front End User Interface
Decentralized (Self-sovereign) Identity Decentralized Payment System
Core functionality for dApp
Application Token
Private or
Permissioned
Data Layer
(Thin) Centralized Backend
- Basic business logic
- ML microservices
- Application data
- APIs to other systems
- Other Oracles
Users of all roles

9. Application Complexity Rises
Decentralization becomes less Black and White
Software
Centralized Decentralized
Centralized
Traditional fiat subscription
SaaS Software
SaaS Software with
Tokenized ownership/
member model
Decentralized
Enterprise private network
coordinating across silos
Fully Decentralized
Network with simple utility
token or no token
Business Model
C
C
D
D

10. N-Party Coordination Markets
A hybrid Blockchain + Artificial Intelligence Use Case
• Capturing the Conditional Commitments of all potential
participants
• Identifying a Feasible Coordinated Event, a non-empty rule-set
intersection
• Proposing an outcome, choosing a point in the feasible set based
predetermined social utility
• Validating that a proposed outcome is valid with respect to all of
the conditional commitments and blocking the commitments into a
coordinated service
• Facilitating or orchestrating the completion of the coordinated
service (multi-party workflow)
• Enforcing the completion of commitments by selected participants
Coordinated outcome
Examples: ODEM (Education), Builder Chain (Construction), Fr8 Network (Logistics), …

11. On Demand Education Marketplace
Participant Roles in an ODEM Event
• Educator (at least one)
• Students (many)
• Auxiliary Service providers
• Translators, Facilities, travel, lodging, catering, etc
Types of Rules or Requirements
• Time, Place, Language
• Topic of Curriculum, Length of Curriculum
• Accreditation of Educator
• Costs for students, Compensation for service providers
Conceptual Overview of ODEM
(Not a Technical Diagram)

12. ODEM - Highlighted Components
Front End User Interface
Decentralized (Self-sovereign) Identity Decentralized Payment System
Core functionality for dApp
Application Token
Private or
Permissioned
Data Layer
(Thin) Centralized Backend
- Basic business logic
- ML microservices
- Application data
- APIs to other systems
- Other Oracles
Users of all roles

13. On Demand Education Marketplace
ODEM Token
• Community Driven Development
• Platform fees cover the operational cost
of running the network
• Use of protocol level tokens for
subsystems are abstracted from the users
• Discount token is used to offset platform
fees in the manner of a co-op
• Token is ‘activated’ not paid so it works
like a membership or a license
• Tokens remain locked in the activated
state (unable to be transferred) until the
completion of the program for which they
are providing a discount
ODEM Program Generator
• All users can submit conditional
commitments representing services they
would provide or consume
• Pre-commitments are broadcast on the
ODEM ledger including all necessary
acceptance criteria for the user
• A centralized machine learning service
will organize these commitments into
mutually acceptable blocks
• A candidate block must be accepted as
valid by the network before commitments
are considered binding
• ODEM notifies all members of the
program when it is formed and off-chain
software and managed services facilitate
the fulfillment of the educational program
• Completion of commitments, including
services, attendance, payments. etc are
logged in the ODEM ledger
Application Token Core Functionality
Other Elements
integration with a protocol level solutions for:
Payments, Identity and Data

14. Discount Tokens: Utility for User Applications
Tokens in use:
Locked for the period
Based on level of service
Tokens owned
Purchase tokens
Sell tokens
Market value of
tokens owned
Discount
capacity of
tokens owned
Network state:
Total tokens activated
Total platform use
Token utility:
Financial value of using the
tokens based on costs offset
over a five year perioduse
From Discount Token Framework Published by Sweetbridge Inc
https://images.sweetbridge.org/main/WP-Sweetbridge-Discount-Tokens.pdf
Discount Token
reduces platform fees by a percentage
F = total fees Networkwide
f = individual user fee without token
A = total activated tokens networkwide
a = individual user activated tokens
user’s discount = phi * a/A*F/f
phi = networkwide discount rate
zero fee when: a = f/F *A/phi
Utility NOT dependent on Token Market Price