►
Description
Hyperledger member, Altoros presented a demo of decentralized platform for peer to peer securities transfer powered by Hyperledger Fabric at Consensus in May 2018.
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #Blockchain
A
A
So
current
current
state
securities
settlement
processes
kind
of
a
well
in
though
use
case
for
for
blockchain
at
this
point,
but
in
the
traditional
implementation,
can
be
a
very
slow,
somewhat
tedious
process
for
banking
institutions,
a
lot
of
processes
done
manually
and
in
terms
of
the
verification
of
both
sides
of
transaction
and
the
the
verification
steps
that
are
typically
involved
and
wool
and,
in
most
cases,
involve
at
least
three
three
active
parties
and
the
settlement
process.
Being
that
depository,
the
issue
of
the
security
and
the
the
investor.
A
So
the
solution
here
in
this
case
mirrored
that
that
network
or
that
group
of
participants,
so
you
had
the
depository
institution
that
was
helping
to
administer
the
network
and
set
it
up
process.
What
were
ultimately
the
blockchain
orders,
creating
the
security
that
would
be
represented
on
the
blockchain
or
the
asset
represented
on
the
blockchain
and
and
lastly,
perhaps
most
importantly,
maintaining
the
the
banking
records
of
the
other
parties
involved
so
we'll
step
through
just
that.
A
So
you
have
a
two
peer
network
with
the
the
third
parts
have
spent
being
the
depository.
So
in
terms
of
channel,
is
you
end
up
with
a
common
channel
kind
of
a
broadcast
channel
representing
information,
our
activity,
that
is,
that
can
be
seen
by
all
participants,
this
general
used
for
querying
what
assets
have
been
created
and
what
assets
are
available
within
the
full
network.
A
There's
the
depository
channel,
which
is
centrally
depositories
own
maintenance
of
the
the
balances
of
the
participants
on
on
the
chain
and
the
the
logging
of
all
asset
transfers
and
their
corresponding
payment
structures.
Then,
importantly,
to
bilateral
channels-
and
this
was
kind
of
the
main
ask
a
request
of
the
use
case.
The
the
participants
wanted
to
be
able
to
engage
in
peer-to-peer
transactions,
engage
in
a
peer-to-peer
asset
transfer,
but
the
balance
information,
essentially
each
participants,
private
banking
information
as
to
essentially
totals
or
items
of
their
balance
sheet
and
an
account
account
balances.
A
They
did
not
want
to
be
visible
to
the
other
participant,
so
the
NSD
essentially
was
kind
of
the
Clearinghouse
or
and
settlement
processor
for
those
balances.
So
each
participant
could,
on
their
respective
channel
view
their
balances,
but
not
have
that
information
be
visible
to
the
other
participant
and
then
ultimately,
for
transacting.
There
was
a
three
party
channel
for
both
both
the
piers
and
the
DNS
D
institution.
A
So,
and
essentially,
the
distinction
between
this
and
a
common
channel
is,
if
you
can
picture
ultimately
and
in
the
future,
is
the
intention
of
adding
more
parties
and
having
this
be
a
kind
of
widespread
network
with
NSD
in
the
center.
Each
transacting
trio
would
be
represented
by
this
sort
of
channel
and
then
all
participants,
so
it
could
be
five
six
or
more
would
collectively,
beyond
the
common
channel.
So
in
terms
of
chain
code,
the
smart
contract
logic
employed
on
the
network,
one
of
a
one
of
the
smart
contracts
was
booked.
A
This
was
deployed
on
that
depository
channel
and
was
essentially
in
charge
of
maintaining
the
records
of
the
various
quantities
held
by
each
member
and
then
was
updated
upon.
Receiving
events
for
secured
transfer
instruction
is
essentially
the
smart
contract
logic
that
executed
the
securities
transfer.
So
this
would
be
on
the
three
participant
channel
between
the
two
peers
and
NSD
and
would
record
and
log
the
the
transfer
quantities
of
all
the
securities
the
security
issuance
is
executed
on.
A
The
network
position
is
essentially
the
smart
contract
executing
that
banking
account
type
of
information,
so
each
peer
with
NS
d1.
They
wanted
to
query
off
the
ledger
to
see
an
update,
their
their
holdings,
their
their
positions
individually.
This
was
executed
on
the
position
contract,
the
security
finally
being
on
the
common
channel,
which
is
really
just
a
a
running
ledger
of
all
the
assets
that
had
been
created
on
the
network,
so
the
ultimate
solution
allowed
for
like
creation
of
any
blockchain
representing
asset
or
any
asset
that
was
to
be
recorded
on
the
blockchain.
A
In
terms
of
the
technology
stack,
this
was
utilizing
an
hyper
ledger
fabric,
so
all
tauros
design
and
implemented
a
client
facing
web
interface
and
also
at
the
time
for
the
version
of
hybrid
ledger
fabric.
The
the
rest
API
was
somewhat
in
development,
so
there
was
some
work
that
alturas
did
also
to
develop
sort
of
customized
rest
interface
for
the
the
web
facing
UI
to
interact
with,
so
that
will
jump
over
quickly
to
the
demonstration.
A
A
So
this
again
being
the
centralized
view
that
is
available
to
NSD
and
the
we'll
see
in
a
moment
here
that
each
of
the
other
participants
can
see
transactions
or
transaction
history
for
the
assets,
but
their
balance
positions.
The
sensitive
cash
cash
position.
Information
you'll
see
here
that
they
see
a
unique
slice
of
that
data
particular
to
their
organization,
and
they
do
not
see
the
the
other
organizations
holdings.
A
So
to
two
primary
issuance
or
settlement
mechanisms
that
were
employed
in
the
solution
very
common
in
the
financial
settlement
space,
so
free
of
payment
and
delivery
versus
payment
mechanisms
and
the
logic
employed
is
a
fairly
simple
matching
logic.
So,
essentially,
both
both
parties
would
initiate
the
same
transaction
command
on
that
instruction
chain
code.
One
would
one
would
be
initiating
the
transfer
and
one
would
be
initiating
the
receipt
and
the
logic
employed
required
that
all
the
metadata
that
you
can
see
here.
A
A
And
so
we'll
still
see
here,
each
each
participant
sees
the
transaction
or
their
side
of
the
transaction
that
they
have
initiated,
and
then
you
see
on
NSD
there
is
the
the
dual
view
of
both
of
those
chain
code
invocations
that
were
used,
so
here
we'll
run
briefly
through
the
similar
transaction,
so
that
was
free
of
payment
and
then
the
second
demonstration
here
being
a
delivery
versus
payment.
So
just
requires
also
including
some
of
that
balance.
Account
information
also
needs
to
match
in
the
event
that
it's
delivery
versus
payment.
A
And
it
is
in
in
that
sense
that
this
we
feel
will
it
will
is
an
important
use
case,
and
one,
at
least
for
the
immediate
future
now
permanently
will
will
continue
to
be
frequently
required
in
the
sense
that
if
parties
are
transacting
with
traditional
fiat
currencies
but
want
the
transaction
history,
the
ledger
to
be
on
blockchain.
It's
it's
it's.
A
A
A
So
here's
some
of
that
additional
detail
required
for
delivery
versus
payment,
matching
that
transfer
that
needs
to
occur
again
also
needs
to
be
needs
to
be
100%,
matched
for
the
instruction
chain
code
to
validate
the
transaction
request
and
process
it.
So
we
see
matched
there
briefly,
as
the
transaction
is
processing
and
then
moves
to
executed.
A
And
each
side
seeing
the
transaction
event
and
the
ledger,
and
now
here
NST
we
see
the
balanced,
is,
have
updated
and
revised
the
quantity
transferred,
that's
a
Gert
and
then
again
that
both
both
sides
of
the
transaction
logged
within
the
the
NSD
but
ER
through
its
through
its
bulchenko
and
each
side
again
sees
their
updated
positions
in
terms
of
security
and
their
cash
position,
but
does
not
see
the
other.
The
other
party
side
shown
in
the
main
requirements.