►
From YouTube: Baseline Summit 2020 Track6 Tokenization - Edited
Description
The complete footage of this track from the Baseline Protocol Summit, from November 12-13, 2020, edited to remove blank sections from the livestream.
For more information on the Baseline Protocol, go to https://baseline-protocol.org
To compete in the Baseline Gitcoin Hackathon (Dec 9 2020 through January 6, 2021), sign up here: https://gitcoin.co/hackathon/baseline/onboard
A
B
B
D
B
B
Okay,
yes,
you
did
mention
this
before
I
remember
now.
Is
that
so
yeah,
it's
good
get
through.
A
C
Yeah
I
was
yeah,
I
was
kind
of
watching
some
some
some
sessions
and
yeah
danielle
did
sort
of
webinar
style
from
vision,
but
in
the
other
session
there
was
more
discussion.
So
john
was
also
in
there.
So
he
was
trying
to
push
some
people
to
talk
and
that's
good.
C
C
C
C
Yeah-
and
I
liked
I
liked
the
opening
also
very-
it
was
very
good.
C
And
ogden,
are
you
you
from
the
between
or
not
yes?
Yes,
yes,
but
also
doing
some
developing
for
us
uni
right
or
not.
A
E
D
B
So
we'll
have
stephen
brian,
we
should
have
karthik
andreas,
I
don't
know
if
we
will
see
any
anything
of
kyle,
I
think,
but
maybe
we
will
kyle.
E
F
B
Yeah,
so
I
think
if
we
have
this
type
of
attendance,
we
can
definitely
stick
in
the
same
group
because
so
from
what
I've
seen
that
everybody.
But
we
will
see
when
we
get
there
and.
A
B
D
D
B
Yes,
I
will
be
sharing
the
slides.
We
have
a
couple
of
yeah
cointy
offices
and
phone
book
great
great.
A
G
B
A
B
B
H
Just
as
a
heads
up,
I
don't
know
if
you're
gonna
have,
you
know
multiple
flow,
and
you
know
the
discussion
phone
book
is
hot
and
heavy
at
the
moment,
so
you
know
we'll.
Let
people
know
that
you're
getting
ready
to
start
and
we'll
keep
funneling
them
your
way.
A
I
F
F
F
B
B
B
B
B
Okay,
I
think
we
can
start
now,
I'm
considerate
of
time
as
well,
because
I
know
stephanie
will
have
to
go
in
one
hour.
So
it's
better
that
we
kick
start
now.
B
Okay,
so
for
those
of
you
here
or
on
youtube
during
this
now
good
morning
and
good
afternoon,
everyone
so
thank
you
for
joining
the
tokenization
and
digital
asset
track
before
jumping
straight
into
the
topic.
As
you
know,
this
is
a
working
session.
We
will
still
take
like
10-15
minutes
to
introduce
ourselves
and
to
make
sure
that
we
are
all
aligned
on
the
topic
what
we
are
working
on
and
the
expected
output
of
the
session.
B
B
D
Yes,
thank
you,
nice
hi
everybody.
This
is
kurti,
chogyan
speaking,
I'm
a
cto
of
a
belgrade
based
startup
in
between
that's
belgrade
in
serbia
and
we're
doing
our
own
a
mission
to
try
to
provide
liquidity
to
small
and
medium
enterprises
through
invoice
factoring
and
with
in-waste
tokenization.
So
I'm
really
eager
to
hear
to
hear
this
topic
related
to
baseline,
as
an
eyes
also
said,
feel
free
to
reach
me
through
through
the
zoom
chat,
for
whatever
questions
or
separate
discussions
during
the
the
summit
and
enjoy.
B
You
so
as
a
reminder,
this
is
a
working
summit
and
it's
an
opportunity
for
all
of
us
to
address
the
subjects
that
we
will
discuss
and
present
today,
but
it
is
also
a
good
opportunity
to
identify
project
candidates
for
the
base
and
accountants
scheduled
in
december.
B
If
you
want
to
add
your
contribution
in
the
track
directly,
we
have
a
notes
tab
here.
They
are
clear
and
straightforward
instruction
on
how
to
do
so.
It
will
be
very
helpful
for
future
reference
and
for
the
conversation,
if,
when
you
add
a
working
note
or
an
idea
that
you
put
the
initial
of
your
name
as
you
see
in
the
example
here,
but
most
of
the
work
that
we'll
be
doing
today,
we
will
capture
through
our
mind
map
and
you
will
find
the
link
in
directly
in
the
notes
tab
here.
B
So
the
might
map,
as
you
can
see,
focuses
on
three
core
themes
that
we
will
address
successfully
so
three
session
or
45
or
40
45
minutes
five
minutes
to
regroup
and
10-15
minutes
to
present
the
outcome.
So
for
each
of
those
key
working
theme
here
we
will
have
one
tab.
B
B
So
the
focus
for
today
is
how
to
convert
a
baseline
record
into
an
on-chain
asset.
What
is
the
interaction
between
that
baseline
record
and
the
onset
asset,
and
how
do
we
manage
the
whole
process
so
more
of
about
governance?
B
So
we
will
try
to
answer
some
of
the
question
below
and
any
additional
one
really
that
will
emerge
through
our
discussion
and,
as
I
mentioned
before,
we
will
allocate
40
minutes
to
every
core
theme.
We
will
concentrate
on
those
and
then
we
will
aggregate
the
result
in
15
minutes
and
then
we
will
present
so
for
anybody.
How
many
are
we?
We
are
12,
so
I
don't
think
we.
A
B
B
Yeah
exactly
that's
perfect,
thank
you.
So
when
addressing
the
key
questions
so
covering
data
process
requirements
infrastructure,
we
will
hopefully
get
a
good
idea
of
what
the
data
model
should
look
like.
What
are
the
methods
and
implementation
options,
but
also
I'm
sure
we
will
identify
key
problems
and
issues
to
be
addressed.
So
the
expected
output
for
that
track
is
really
to
have
items
that
address
all
of
those
all
of
those
items
here.
So
I
think
we
are
ready
to
get
started.
That's
it
for
the
formalities.
D
Okay,
thank
you,
nice.
So
most
of
you
are.
The
assumption
is
that
most
of
you
are
aware
of
the
baseline
already,
either
through
some
research
before
the
summit
or
during
the
first
workshops
on
the
summit,
and
these
are
just
some
of
the
key
definitions
that
we
are
going
to
talk
about
just
so
that
we
are
on
the
same
page.
D
When
we
talk
about
an
off
chain
asset,
we
are
talking
about
an
asset
that
is
a
record
or
a
document
that
is
stored
in
the
system
of
record
in
the
earpiece
system,
or
a
google
doc
sheet
or
whatever
system
of
record
that
the
parties
would
use.
D
When
we
talk
about
the
circuit,
that
is
a
mechanism
to
validate
a
set
of
business
rules,
often
or
on
chain
using
the
zero
knowledge
proofs,
and
this
is
the
mechanism
that
that
enables
the
shared
state
in
the
end
in
the
baseline
world,
the
on
chain
baseline
proof,
the
so
the
verifiable
evidence
that
is
publicly
available.
That
something
has
happened,
that
the
record
or
document
has
passed
through
some
set
of
business
rules.
D
A
D
Right
and
in
the
end,
we
have
the
work
step
which
a
number
of
them
constitute
a
workflow,
and
these
are
discrete
processes
or
operations.
D
A
J
D
Kind
of
use
case
more
and
more
intriguing
and
more
interesting
for
discussion.
We
can
just
jump
over
these,
so
the
first
one,
the
invoice
financing
where
we
have
a
two
companies
supplier
and
the
buyer,
and
we
have
a
invoice
financing
platform.
Let's
say
as
a
third
party
that
are
part
of
our
group
and
the
goal
is
of
course,
invoice.
Tokenization.
The
supplier
wants
to
get
money
in
advance
for
the
invoice.
D
We
have
the
exchange
of
invoices
via
baseline,
where
that
which
is
a
record
or
a
proof
that
this
transaction
behind
the
invoices
happened.
And
then
we
also
have
the
tokenization
platform,
which
would
take
that
invoice
and
then
create
out
with
a
financial
instrument,
so
to
say
which
is
tokenized
and
then
given
to
the
public
or
to
the
group
of
investors
to
to
invest
in
it.
D
There
is
the
use
case
of
project
capital
funding
where
you
have
a
group
of
construction
companies
that,
for
example,
want
to
acquire
capital
to
start
a
new
project
and
they're
part
of
a
baseline
regroup,
where
they
can
together
joint
manner,
work
on
the
project,
and
then
this
project
can
be
tokenized
or
offered
to
investors.
D
All
of
them
have
a
lot
of
in
common,
of
course,
and
the
differences
are
minor.
You
would
mostly
think
in
the
when
you
think
about
the
differences
in
these
use
cases,
you're
thinking
about
token
standards,
for
example,
that
would
be
used,
you're
thinking
about
the
amount
of
deployments
or
tokenizations.
That
would
happen
so,
for
example,
in
the
first
use
case,
you
can
expect
really
a
lot
of
deployments,
while
in
the
second
use
case,
you
really
would
not
have
that
much
pair
of
regroup
and
some
other
minor
differences
that
we
could
touch
during
the
discussion.
D
D
Do
that
for
40
or
something
like
minutes,
thus
assemble
the
results
and
then
move
to
the
next
one
which,
which
is
the
tokenization
the
process
of
tokenization
and
the
last
one
is
tokenization
talking
governance
with
the
prerequisites.
What
we
want
to
touch
or
what
we
identified
as
some
interesting
topics
is
the
data
and
the
schema.
So
what
is
what
would
be
a
standardized
standardized
set
of
fields,
that's
needed
in
a
web
group
before
you
can
even
think
about
tokenizing
an
asset,
the
authorization
so
who
would
be
the
owner
are
there?
D
Is
there
need
for
multiple
owners,
multi-sigs
and
so
on?
What
is
the
cost
distribution
so?
Who
is
paying
for
the
tokenization
of
a
group?
Is
there?
Is
there
a
need
to
have
that
you
have
a
shared
wallet
or
the
entity
who
is,
for
example,
requesting
financing?
D
Is
the
one
who
is
responsible
to
pay
for
a
transaction
so
on
the
token
standards
that
would
be
needed
to
be
supported
by
the
protocol,
and
then
we
have
the
privacy
and
the
security
obvious
obvious
requirements
in
the
you
can
move
to
the
next
one
in
the
tokenization
process.
D
We
are
talking
about
the
deployment
steps,
so
is
there
a
need
for
a
circuit
to,
for
example,
validate
the
to
be
validated
just
before
the
asset
is
tokenized?
What
would
be
the
architecture
of
the
tokenization
module?
Is
that
should
that
be
a
separate
baseline
infrastructure
service
similar
to
the
privacy
service?
D
Is
that
done
through
some
kind
of
a
smart
contract
architecture
and
the
the
process
of,
for
example,
selecting
the
token
standard?
So,
let's
say
you
have
a
group:
do
you
do
you
want
to
have
an
option
to
change
the
token
standard
that
is
being
used,
or
do
you
just
stick
with
one
which
is
which,
with
when
the
workgroup
was
initially
deployed
the
last
one,
so
that
the
government's
quite
an
interesting
one?
What
do
we
do?
For
example,
if
you
have
a
lot
of
token
contracts
that
are
deployed.
A
D
Do
you
handle
upgrades
to
those
contracts?
How
do
you
handle
bugs
in,
I
don't
know
100
deployed
contracts
who
is
going
to
do
the
administration
a
similar
topic,
like
the
topic
of
ownership,
I
mean
all
of
all,
of
these
three
topics
are
overlapping,
so
it's
not
really
a
clear
cut
and
the
topic
of
state
sense
synchronization.
A
D
The
gap
between
the
baseline,
the
asset
off
chain
and
the
token,
which
is
unchanged
how
to
make
sure
that
they
are
always
in
the
same
state.
B
So
yes,
so
we
basically
presented
the
three
pillars
that
we
will
successively
address
to
try
to
answer
the
key
questions.
So
what
I
propose
now
is
that
we
move
to
the
mind
map
so
again
as
a
reminder,
because
some
people
just
joined
us
now,
if
you
add
any
notes,
please
do
as
your
initial
year,
we
have
already
structured
the
note
document
for
each
session
so
feel
free
to
add.
We
will
only
have
one
group
because
there
is
13
of
us
on
the
call.
So
please
disregard
this.
B
Okay,
great
thank
you
and
I
think
I
will
start
the
timer
and
we
can
focus
on
tokenization
prerequisite.
B
Can
we
identify
call
field
that,
regardless
of
the
recall
type,
the
document
type
of
the
asset
type
will
always
be
needed
so
from
a
baseline
point
of
view?
Obviously,
so
any
record
that
is
baseline
and
subject
to
tokenization
do
we
need
a
set
of
required
field?
Similarly,
for
metadata,
we
can
think
about.
B
B
D
Example,
it's
a
good
question,
the
the.
Why
would
you,
depending
on
the
use
case,
what
why
would
you
need
versioning
for
if,
let's
say
you
in
the
invoice
factoring
use
case,
you
have
a
prepared
financing
instrument,
which
was
an
invoice
that
was
great
risk,
assessed,
verified
and
so
on,
and
you
would
just
present
or
create
a
token
out
of
it,
which
is
then
for
60
or
90
days
are
just
there
to
reflect
the
ownership
of
potential
investors.
A
D
B
Yes,
so
could
so
if
we
have
a
current
version-
or
you
know
previous
version
fields
to
capture,
but
similarly
in
terms
of
id
in
a
given
system
of
record,
if
I
think
about
salesforce,
an
invoice
record
will
have
the
business
id.
So
following
the
naming
convention
within
that
company,
it
will
have
the
salesforce
id
as
well
and
do
we
need
something
similar
as
baseline
id.
So
if
we
have
a
token
id
on
chain,
is
it
and
I'm
just
putting
idea
out
there
so
either
irrelevant?
We
just
you,
know,
push
them
away
away
like
very
so.
B
But
those
are
the
type
of
data
points
that
on
the
system
of
record,
we
may
need
to
consider,
because
is
there
any
need
for
synchronization
post
update
or
things
like
that,
we
may
need
to
refer
to
them
as
well.
I
Just
dropping
in
here,
hello
from
from
unibright
and
also
part
of
one
of
the
baseline
stories
in
the
in
the
github
that
runs
that
tokenization
project,
I
think,
what's
what's
always
important,
is
to
distinguish
between
the
the
state
or,
if
you
talk
about
versions
that
somehow
ended
up
in
baseline
and
the
outcome
of
whatever
synchronized
baseline
state
that
led
to
a
tokenization
or
even
a
token
creation.
So
if
we're
talking
about
versioning
after
that
say,
we
have
an.
We
have
a
baseline
invoice
between
two
parties.
I
Then
we
start
the
tokenization
process,
because
we
want
create
a
token
that
represents
that
invoice
and
we
are
talking
about
different
versions
of
that
invoice
because
it's
changed
afterwards.
I
I
think
this
is
a
different
topic
than
if
you're
talking
about
updates
to
the
results
say
the
token
itself.
It
could
be
that
the
the
two
scenarios,
basically
the
underlying
invoice,
that
was
that
was
the
starting
point
for
the
tokenization
changes
or
the
invoice.
The
baseline
invoice
stays
the
same,
but
you
want
to
add
a
versioning
on
the
tokenization
itself,
so
just
putting
that
thought
out
that
we
might
have
to
distinguish
between
these
two
change.
Versioning
update
scenarios
here.
B
I
just
want
to
put
it
out
there
that
if
it's
not
relevant,
we
disregard
directly
so
one
I
one
thing
could
be
what
happens
if
payment
terms,
for
whatever
reason
needs
to
need
to
change
or
if
even
the
legal
entity,
because
there
were
a
situation
in
the
past
where
a
company
was
incorporated
in
the
uk,
for
example,
and
then
the
u.s
company
had
to
move
up
and
then
the
new
eu
became
sorry.
B
Do
we
consider
those
type
of
very
concrete
business
use
case
that
could
impact
an
existing
record
that
has
been
baselined
but
which
will
be
subject
to
change
or
could
be
subject
to
change
payment
terms
being
like
the
most
straightforward
one,
we've
changed
our
bank
account
for
whatever
reason
we
need
to
resubmit
so,
and
we
could
be
that
we
say
this
is
out
of
scope
because
it
has
too
much
complexity
at
this
stage
of
the
conversation
and
we
focus
on
critical
fields
or
data
points
required
for
the
tokenization
process
exclusively.
I
Everything
makes
sense,
I
I
just
don't.
I
don't
have
a
sense
yet
if
it's,
if
it's
the
first
issue
to
to
talk
about,
if
you
I
think,
if,
if
this
session
leads
to
a
clear
understanding,
what
is
actually
the
transition
from
the
baseline
record
to
a
created
token,
then
perhaps
it's
more
obvious,
for
example,
the
payment
terms
example.
What
is
due
to
potential
changes,
yeah.
D
So
that's
payment
term
changes
is,
in
my
view,
a
really
exceptional
thing
when
it
comes
if
you're
talking
about
invoice
factoring-
and
this
is
something
that
needs
to
be
taken
care
of
by
the
business
logic
and
by
the
methodology
of
the
company
doing
the
invoice
financing,
and
this
on,
I
would
put
it
under
the
umbrella
of
state
updates
between
the
baseline
asset
and
and
the
tokenized
asset
when
it
comes
to
versioning
in
the
sense
of
you
have
a
api
of
your
token
contract,
which
is
a
token
standard,
and
then
there
is,
I
understood
your
question
was
going
in
that
direction
and.
B
G
B
Okay,
we
I
see
that
we
have
now
brian
mars
on
the
car
as
well.
Are
there
any
input
on
your
side
or
tv?
Then
we
have
a
couple.
B
D
Yes,
yes,
so
if
you
take
the
the
case
of,
for
example,
invoice
financing,
the
workgroup
participants
would
be
three
parties,
so
you
would
have
the
supplier,
the
buyer
and
the
platform
who
is
technically
enabling
the
tokenization,
but
the
people
from
whom
you're
taking
the
money,
those
could
be
funds
or
private
persons.
You
would
not,
then
expect
them
to
be
part
of
the
baseline
work
group.
D
They
would
just
come
to
a
platform
which
is
enabling
them
to
invest
their
money
short
term
in
in
waste
factoring
on
financing,
and
they
actually
don't
even
don't
need
to
know
that
there
is
a
blockchain
behind
it
right.
That
really
depends
on
the
again.
How
does
the
invoice
factoring
or
invoice
financing
platform
wants
to
market
itself?
K
Also
yeah
yeah,
no,
so
as
a
follow-up
to
that,
wouldn't
it
be
relevant
to
an
investor
or
bank
as
to
exactly
what
has
been
baselined.
Wouldn't
that
be
relevant
information.
Yes,.
D
A
D
D
But
if
you
want
that,
would
that
could
also
imply
that
you
would
need
to
have
them
as
part
of
the
group
so
that
they
can
verify
the
proofs,
and
then
that
introduces
a
number
of
business
issues,
because
your
network
for
invoice
financing
would
right
need
to
all
of
these
participants
would
need
to
have
baseline
infrastructure,
so
it
really
depends
on
the
use
case
on
some
use
case.
Yes,
on
some
use
case,
no.
K
Yeah,
so
could
you
give
an
example
of
jan
like
what
would
be
baseline
for
a
typical
invoice
like?
Would
it
be
someone
one
company
saying
we
issued
a
purchase
order
and
another
company
saying
we
issued
an
invoice
and
then
the
company
that
issued
the
purchase
order,
acknowledging
that
invoice
like
just
so
I
can
get
some
contacts.
D
D
K
And
if
an
investor
group
did
again,
this
sort
of
indirectly
relates
to
data,
but
if
the
investor
group
wanted
to
make
a
claim,
because
an
invoice
hadn't
been
settled
through,
you
know
they
hold
the
token,
would
they
they
have
to
do
it
through
a
supply
through
the
supplier
that
originated
the
invoice
or
could
they
do
it
direct?
I
mean.
D
A
D
If
you're
doing
invoice
factoring
it's
the
third
party
or
the
factoring
company
who
who
should
then
if
it's
factoring
with
recourse
first,
should
follow
the
buyer
and
then
try
to
get
money
from
the
supplier?
If
the
buyer
fails,
then,
if
you
have
private
investors
who
are
actually
participating
in
financing
of
those
invoices
depends
on
their
deal
with
the
with
the
platform
who
is
providing
them.
The
services
who
is
taking
the
risk
is
the
risk
shared.
Is
it
completely
on
the
investor
side?
D
Is
it
completely
on
the
platform
side,
it's
really
a
huge
amount
of
different
use
cases
that
could
come
out
of
it.
The
important
point
is
that,
through
the
baselining
between
the
supplier
and
the
buyer,
you
you
get
this
additional
value,
that
you
have
a
proof
that
something
has
happened,
which
is
currently,
for
example,
in
factoring,
could
be
a
source
of
fraud.
Okay,.
B
Well,
I
guess
it
depends
of
the
use
case
as
well,
but
just
as
a
reminder,
the
point
is
to
say:
can
we
find
commonalities
which
are
use
case,
which
are
not
specific
to
use
cases
where
we
can
propose
best
approaches
or
best
step
best
process
for
the
tokenization
prerequisites?
So
I
know
agnes.
You
had
some
idea
about
how
cost
distribution
would
work
for
invoice
factoring.
So
we
can
start
by
season
yeah.
D
I
was
just
thinking
in
general
terms
in
two
directions.
One
direction
is
that
costs
are
shared,
meaning
that
when
you
set
up
a
work
group,
you
have
some
kind
of
a
shared
wallet,
for
example,
that
all
the
participants
would
need
to
fill
up
to
a
certain
amount.
It
could
be
a
multi-sig
wallet
and
the
funds
are
coming
in
proportionally
based
on
whatever
is
being
tokenized,
and
the
other
option
is
that
the
initiator
is
is
providing
its
own
own
money
for
for
doing
tokenization.
B
If
that
step
is
somehow
yeah.
Yes,.
D
Depends,
I
guess
it
depends
on
having
the
party
in
between.
So
if
you
have
a
factoring
company
or
an
invoice
financing
platform
in
between
the
supplier
and
buyer,
they
would
probably
for
their
services.
They
would
get.
A
D
B
Yes,
is
there
something
to
be
said
about
predefining
how
the
token
owner
will
have
access
if,
if
needed,
to
the
option
asset?
So
if
we
have
a
case,
for
example,
where
we
are
not
taking
inverse
organization
particularly,
but
if
we
have
a
specific
project
requiring
financing
as
an
investor,
I
will
need
to
see
a
certain
number
of
documents
right,
so
the
investment
details
or
the
the
project
details
will
not
be
anonymous
or
private
in
the
same
way
that
potentially
invoiced
organization
could
be.
B
So
I
think
when
it
comes
to
authorization
and
permission,
of
course
it
is
use
case
specific.
But
what
are
the?
Is
there
any
like
standout
or
approaches
that
we
can
say
there
are
two
use
cases
either
the
the
underlying
option
asset.
I
invoice,
for
example,
should
remain
private,
so
we
don't
need
to
know
who
the
supplier
and
who
the
buyer
is.
We
don't
need
to
know
a
volume
we
don't
need
to
know,
and
second
is
we
actually
need
full
visibility?
B
The
investor
need
full
access,
so
those
are
the
two
things
based
on
the
use
case
that
we
have
presented
before.
So
my
question
is
in
the
second
case
where
I
actually
do
have
so
the
the
there
is
a
token
out
there,
as
an
investor
appreciates
the
token.
What
is
the
mechanism
to
give
me
visibility
back
or
to
linking
me
back
to
the
option
record
or
official
document.
K
Can
I
guess
my
question
was
sort
of
tied
to
that
as
an
investor,
I
would
think,
because
we're
dealing
with
virtual
assets,
virtual
tokens
or
digital
tokens
against
sort
of
real
wild
assets,
I'd
probably
need,
as
a
prerequisite
an
acknowledgement
from
either
the
the
the
supplier
and
or
the
the
provider
of
the
the
product
or
services
that
they
will.
They
will
allow
assignments
of
of
the
rights
under
that
digital
asset,
so
that
you
know
you
know
if
I
do.
K
If
something
goes
wrong
in
the
real
world,
because
I
I
purchased
a
digital
asset
and
financed
it,
I
need
the
assurance
that
the
I
guess,
the
the
the
person
behind
the
services
will
will
honor
the
the
invoice
if
it's
held
by
a
third
party
and
and
I'm
just
wondering
why-
that
fits
into
sort
of
the
protocol.
K
Not
really
the
regulation,
I
mean,
if
I'm
going
to
buy
a
digital
asset
right
and
and
worst
case
happens.
You
know,
payments
aren't
made
someone's
going
to
have
to
recover
against
my
my
security,
which
is
the
digital
asset,
so,
regardless
of
whatever
regulation,
because
I'm
sure
every
country
has
different
regulation,
I'm
going
to
need
some
sort
of
proof
that
the
provider
of
the
goods
that
sorry
the
buyer
of
the
buyer
of
the
goods
is
will
will
honor
the
invoice.
If
I
hold
them
right
in
real
world.
B
Yeah,
so
I
guess
it's
part
of
the
credit
check
validation
that
the
factoring
company
would
do
right
and
one
way
is.
There
are
two
ways
really
as
a
factoring
company.
When
I
receive
an
invoice,
I
need
to
qualify
it,
so
I
need
to
check
the
credit
score
of
the
supplier
of
the
the
buyer
and
your
question
is
as
an
investor.
I
want
to
have
this
certainty,
so
I
need
to
have
access
to
that
proof.
I
don't
want
to
trust
that
the
factoring
company
you
know
is
doing
because
I
don't
know
the
criteria
to
validate
that.
B
This
invoice
is
good
enough
to
be
presented
to
investor.
So
this
is
again
putting
that
proof
that
this
step
of
the
process,
which
is
credit,
check
or
credit
score
or
credit
risk
assessment
as
well,
has
been
done
and
has
been
done
by
a
third
party.
So
now
some
credit,
sorry,
some
factoring
company
may
say:
look
we
have
our
own
internal,
you
know
scoring
system
and
we
only
rely
on
third
party
for
a
credit
risk,
but
in
terms
of
setting
the
discount
rate,
so
we
do
it.
So
investor
may
feel
like
no.
B
We
want.
Third,
like
third
party
financial
institution,
to
kind
of
you,
know,
risk
assets
and
recommend
best
rate
for
this.
So
once
again,
this
is
a
bit
implementation
specific
because
both
can
be
done
if
there
is
a
need
to
do
so,
it
can
be
by
api
or
oracle,
providing
this
like
risk
assessment.
So
does
that
answer
your
question,
but
all
of
these
once
done
this
can
be
part
of
the
business
rules
that,
when
we
do
this
check,
this
step
needs
to
be
verifiable
on
chain.
B
K
Yeah
yeah,
I
I
guess
it's
a
bit
more
than
that.
I'm
thinking
I'm
in
canada
right
now
right
so
I
believe
in
canada.
If
someone
a
supplier
sells
sorry,
a
supplier
delivers
goods
to
a
company
and-
and
they
basically
have
a
registered
claim
on
that
good
under
canadian
law
may
be
different
in
other
countries
until
that
invoice
has
been
settled.
K
A
D
Make
you
purchase
the
token?
This
is
something
which
is
usually
sold.
So
let's
say
there
is
this
invoicing
platform
or
factoring
company.
However,
you
want
to
call
it
and
it
offers,
through
tokenization
to
its
investors,
to
participate
in
invoice
financing
and
the
factoring
company
would
have
an
agreement
with
each
and
every
investor,
which
is
the
part
of
the
kcml
and
the
onboarding
of
the
customer,
to
say,
for
example,
your
business
model
as
a
factoring
company
is
that
you
can
get
better
rates
returns.
D
If
you
go
with
riskier
invoices,
we
will
perform
the
great
risk
and
we
will
give
you
a
great
risk
grade
that
you
can
trust
or
you
don't
need
to
trust.
If
you
trust
you
will
invest
and
you
are
taking
deliberately
the
risk
that
maybe
this
could
fail
and
that
you
will
not
be
paid
and,
for
example,
if
they
want
to
lower
that
risk.
For
you,
the
factoring
company
could
say:
okay,
let's
tokenize
this
financing
instrument
or
an
invoice,
and
I
will
participate
with
x
percent
and
you
will
participate
with
epsilon
percent.
A
D
Induce
more
trust
into
the
investors,
what's
interesting
with
baseline
here
is
that
you
could.
Actually,
you
would
have
circuits
which
verify
that
something
has
happened
and
that
the
invoice
has
happened,
that
both
parties
agreed
to
it,
and
this
is
something
that
could
potentially
be
also
presented
to
the
investor
as
a
proof.
K
B
So
we
talked
about
authorization
and
permission
on
of
the
ocean
asset,
but
this
is
like
really
linked
to
the
privacy
requirement.
So
in
the
invoice
factoring
use
case,
the
assumption
and
correct
me
if
I'm
wrong
is
that
the
asset
attribute
ied
invoice.
Details,
for
example,
will
remain
private
to
the
investors.
Is
that
correct.
B
B
A
B
Trying
to
identify
if
we
can
have
a
standout
way,
which
is
independent
of
use
cases,
and
it
may
be
that
when
we
start
like
as
we
are
doing
now,
we
realize
no,
that's
not
the
right
way
to
approach.
It
is
either
two
domain
specific
or
is
it
too
use
case
specific,
in
which
case
we
are
still
doing
very
valuable
work,
because
we
have
identified
that
this
is
not
a
good
candidate
like
the
tokenization
process
from
a
baseline
asset
may
not
be
a
good
candidate
for
a
standout
or
specification.
B
Of
the
work
as
well
so
my
question
to
you
and
everybody
on
the
call
is
okay.
We
have
15
minutes
on
that
topic,
so
we
have
address
cost
distribution
and
we
have
said
that,
depending
on
use
case,
the
cost
will
be
distributed
differently,
so
there
is
no
like
standard
way
of
distributing
cost.
We
have
also
said
that,
in
terms
of
authorization
and
permission,
the
future
token
owner
may
not
or
may
or
may
not
require
access
to
the
option
or
slash
underlying
document
or
asset.
K
I
I
heard
you
mention
like
different
use
cases,
the
project,
finance
and
the
invoice.
I
think
in
both
cases
there
will
be
privacy
requirements
in
the
sense
that
if
a
group
of
investors
is
financing
the
project
they're
going
to
want
to
see
the
information
but
likely
the
people
involved
in
that
syndicate,
including
you
know,
the
project
sponsor
and
and
the
investor
group
and
the
intermediary
are
probably
going
to
want
to
see
the
information
related
to
the
project,
but
outside
of
that
group,
they'll
want
to
keep
trying
them.
B
B
B
Yep,
yes,
so
it
means
that
if
we
have
a
use
case
where
the
one
of
the
prerequisites
that
we
have
is
that
the
underlying
or
the
option
asset
should
need
to
be
accessible
to
additional
war
group
members,
it
comes
with
its
own
new
set
of
business
logic
and
all
of
those,
because
the
assumption
of
the
consequence-
not
the
assumption,
is
that
at
some
point
we
may
consider
that
those
investors
want
to
baseline
this
record
with
their
own
system
of
record.
Does
that
make
sense
yeah?
So
I
will
put
so
the
question.
D
D
Maybe
just
regarding
the
privacy
requirements
thinking
in
the
direction,
let's
say
that,
for
whatever
reason,
you're
using
cases
that
you're
producing
a
lot
of
these
token
contracts,
there
is
a
bazillion
of
invoices
that
you're
financing,
but
that
could
be
sensitive
because
if
anybody
knows
the
address
from
which
you
are
working
as
an
invoice
factoring
platform,
they
could
say
how
much
are
you
so
in
that
sense,
the
privacy
requirement
could
be
that
you
hide
the
owner
of
the
of
the
of
the
entity
doing
the
deployments,
for
example
through
through.
A
D
Blockchain
features
that
already
exist.
B
B
B
Do
you
want
to
give
to
tell
us
she
was
about
diamond,
so
can
stand
out.
B
There
is
one
that
I
I
found
sorry,
I
should
have
oops
it's
sorry.
I
did
something
silly.
I
was
trying
to
okay.
B
B
If
you
go
to
the
epic
for
this,
we
have
this
confidential
token
standard
by
aztec.
So
this
is
currently
a
proposed.
It's
not
so
that's
one
of
the
things
that
we
could
explore
as
well.
So
how
do
we
maintain
the
token
itself,
like
the
token
contract
itself
confidential
or
any
other
tokens
that
are
part
of
the
deployment,
so
the
one
that
is
a
good
candidate
for
consideration
is
definitely
that
one.
A
B
A
D
B
D
For
example,
for
the
artwork
use
case
and
for
the
in
the
cases
where
you
have
a
lot
of
deployments,
you
could
go
with
something
like
your
c1155,
which,
which
is
designed
exactly
for
having
a
single
contract
and
multiple
deployments
of
a
token,
greatly
greatly
reduces
the
costs.
So
I
could
envision
that
that
you
would
have
a
service
where
you
can
actually
for
when
you're,
creating
a
work
group
or
a
work
step.
You
could
select
from
a
number
of
implementations
of
token
standards
that
are
readily
available
open
source.
D
D
B
Yeah,
so
what
we
can
really
see
here
that
there
are
not
one
best
way
to
really
tackle
the
tokenization
prerequisites,
and
I
think
this
will
be
the
well.
We
can
take
more
time
because
it's
just
15
of
us,
so
we
can
carry
on
for
another
10
minutes
on
that
topic
before
moving
to
the
other
one.
But
and
please
provide
your
feedback
if
you
disagree
or
if
you
think
that
we
miss
like
something
very
very
obvious.
B
But
it
seems
to
me
that,
based
on
the
like
session
now
it
won't
it
wouldn't
be
the
right
approach
to
be
prescriptive
about
authorization
and
permission,
because
we
can
see
that
they
vary
about.
Tokenization
also
can
stand
out.
One
thing
that
if
we
do
it
well,
we
can
explore
further.
I
am,
I
suspect,
that
the
privacy
in
the
security
requirement
can
be
abstracted
and
applicable
to
all
use
cases,
because
I
don't
foresee
any
business
use
case
where
we
would
want
to
publicize
who
is
doing
the
deployment
and
where
is
the
money
going?
B
It
seems
that
it's
a
no,
but
again,
we've
just
started,
so
it
could
be
that
we
say
that
we
would
not
have
cost
distribution
requirements,
but
we
could
well
have
privacy,
so
one
conclusion
could
be
all
of
those
components
here
are
use
case,
specific
cost,
distribution,
authorization
and
permission
token
standards,
but
maybe
some
permission,
privacy
and
security
requirements
will
be
must
have
regardless
of
the
type
of
asset,
regardless
of
the
use
case
and
regardless
of
the
industry,
and
I
think
this
is
where
maybe
the
conversation
should
be
going
to
be
clear
on
what
is
applicable
regardless
of
use
case
and
industry.
B
D
If
you
go
back
to
the
data
question,
so
the
first
one
topic
that
we
started,
actually
you
could
think
of
something.
That
is
a
must
it's
just
a
link
between
the
the
asset
and
the
token
right,
so
you
would
need
every
one
of
the
tokens
would
need
to
have
a
field
that
identifies
it
uniquely
back
to
the
system
of
record
of
a
baseline
of
a
baseline
asset.
D
B
B
B
Is
it
things
that,
like
things
that
we
will
need
as
part
of
the
legal
address,
all
the
data
points
that
show
that
this?
That
a
given
company
is
a
rightful
owner
of
the.
A
D
D
B
B
B
So
my
baseline
stack
will
send
a
message,
including
the
invoice
which
has
been
serialized
to
the
baseline
stack
oops.
Sorry,
this
is
telling
me
that
we
are
done
sorry
to
the
baseline
stack
of
the
factoring
company
and
the
factoring
company.
After
doing
the
check
that
we
mentioned
before
credit
check,
credit
assessment,
if
approved,
will
send
the
message
back
to
the
suppliers
that
is
approved
and
can
provide
like
can
release
the
cash
basically.
A
B
Independent
of
you
know,
blockchain,
and
this
will
remain
private
in
all
cases,
because
this
is
a
bank
account
payment
that
is
managed
from
the
factory
company
and
the
invoice
sorry
and
the
supplier
between
of
the
invoice.
Basically
so
yeah.
This
is
not
a
problem,
and
it's
not
it's
like
it's
literally
business
as
usual,
I
would
say.
B
A
A
D
Yeah
regarding
to
change
ownership
in
a
private
way,
I
think
the
answer
is
so.
Let's
say
you
have
an
investor
who
is
selling
his
invoice
tokens
on
a
secondary
market
or
something
like
that
and
you
for
whatever
business
reason.
You
want
to
hide
that
changing
of
ownership-
and
I
guess
this
is
also
covered
by
the
standard
or
proposal
that
you
mentioned,
where
you
would
have
a
confident
contract
where
the
ownership
is
actually
not
publicly
accessible.
D
B
Yeah
we
can
take
sometimes
because
we
have
in
the
other
working
session,
we
will
address
standard
again
standard
selection,
so,
depending
on
how
we
are
doing
on
time,
we
can
definitely
take
some
time
and
look
all
of
us
together
and
see
if
that's
actually
a
good
candidate
or
not.
It's
part
of
you
know
the
working
session
so.
K
Also,
the
transfer
of
ownership
is
going
to
be
probably
something
you
want
in
the
data
metadata,
because
you'll
probably
have
some
assets
that
are
assignable,
some
that
are
assignable
with
permission
of
the
issuer
and
some
that
there
are,
there
is
no
assignment
like.
B
B
Yeah,
I
I
think
I
do
so
I
will,
and
I
think
we
will
definitely
develop
that
further,
because
we
have
key
working
items
touching
on
this.
Okay.
Thank
you,
everybody!
It's
all
three!
Well,
eight
or
three
on
my
side,
I'm
based
in
london.
So
if
we
can
come
back
in,
let's
say
12
minutes,
it's
a
like
at
15,
depending
on
where
you
are
so.
I
will
keep
that
open
and
running
and
we'll
be
back
in
10
minutes.
B
B
B
B
B
Hello,
welcome
back.
I
think
we
have
my
well.
We
had
seven
and
nine
people
now
back
so
just
I,
I
captured
the
conclusion
before
we
start
we'll
give
a
couple
of
minutes
to
everybody
else.
B
That
is
not
use
case
and
domain
specific,
and
it
could
be
that
for
data
schema,
most
of
the
core
fields
will
be
related
to
capturing
token
ownership
data
points
legal
entity
legal
address
as
well
as
linkage
to
the
token
once
it
is
minted,
so
reference
to
the
on
chain
token,
the
token
contract
address-
and
we
have
also
mentioned
capturing
like
transfer
ownership,
and
I'm
now
asking
myself
if
transfer
ownership
itself
can
be
governed
by
business
rules
right
if
it's
allowed,
if
it's
not
allowed,
if
it's
allowed
in
what
context,
so
that
could
be
a
good
candidate
to
it's
definitely
a
good
prerequisite
prerequisite
item
because
it
will
be
linked
as
well
to
token
standard
right
to
some
extent.
B
So
I
will
put
it
here
because
kind
of
link
to
both
in
some
use
case.
We
will
definitely
want
easy
transfer
of
tokens-
art
piece,
for
example.
However,
I
don't
foresee
that
if
somebody
or
a
group
is
working
on
a
real
estate
project
that
those
tokens
could
have
like
the
this
type
of
ease
to
transfer.
B
Right,
yes,
yes,
exactly
so,
and
one
thing
that
I
add
is
that
obviously
there
are
many
token
standards
that
could
be
good
candidates,
but
do
we
think
that
there
may
be
one
that
could
cover
most
use
cases
like
standard
use
case
in
the
same
case
in
this,
when
we
have
zero
knowledge
circuit,
we
can
have
a
generic
circuit
for
consistency,
check,
check
right.
It
doesn't
cover
everything,
but
it's
a
basic.
You
know
everybody
will
need
that.
It's
part
of
the
baseline
fabric
that
it
needs
to
exist.
D
A
M
D
B
Okay,
what
time
is
it?
Okay?
So
I
will
start
the
timer
for
45
minutes
on
the
second
session
and
again
feel
free
to
go
back
during
the
summit
or
after
the
submit
to
either
add
your
notes
or
review
those
everybody
can
add
as
permission
sorry
as
access
and
permission
to
edit
those
documents
yep,
it's
now
time.
So
I
think
we'll
up
do
this.
B
So
as
a
reminder
up
where
we
raise
that
to
45,
because
we
are
nine
now
so
the
tokenization
process
is
a
process
by
which
a
token
is
issued
on
the
main
net,
and
this
token
represents
the
on-chain
asset
being
the
document
or
the
record
in
the
system
of
record.
B
So
there
are
really
three
main
things
that
we
should
discuss.
First,
the
token
deployment
steps,
the
technical
architecture
and
then
the
tokenization
standard
selection,
so
one
that
one
of
the
questions
that
I
had
is
what
should
be
the
deployment
step
and
are
there
different
if
we
do
a
one-to-one
relationship
on
option
asset
to
one
token
and
option
asset
to
many
tokens?
B
B
I
will
actually
ask
because
I've
seen
that
joel
melanie
and
w.e
perry
you
have
been
on
the
on
the
call
for
quite
a
while.
Would
you
like
to
contribute?
Is
there
do
you
have
any
ideas
that
you
would
like
to
share
with
us?
Actually
I
don't.
L
This
is
melanie
for
now,
I'm
just
gonna
be
in
an
observer.
I
do
have
a
bit
of
experience
with
baseline
through
my
my
work
at
ernst
young
before
and
kind
of
contributing
to
the
protocol,
maybe
like
six
months
ago,
but
I'm
it's-
I
haven't
touched
it
for
a
while.
So
this
is
just
an
opportunity
for
me
to
kind
of
refresh
myself.
So
sorry,
if
I'm
not
going
to
be
very
active
today,
if
that's
what.
B
None,
though,
don't
worry
that
sorry,
that's
perfectly
okay,
I
guess.
If
there
is
anything
significant
significantly
wrong,
you
can
tell
us
like
oh
hold
on
so
yeah.
That's
good!
I've
just
seen
sorry,
I
wasn't
looking
at
the
check,
so
I
submitted
as
a
point
of
asset
tokenization
is
to
create
an
integral
instrument
of
value
such
as
instrument
will
have,
no
so
for
everybody.
I'm
reading
a
question
that
that
is
on
the
chat
now
so
either
in
the
sense
of.
B
D
B
That's
where
that
works,
if
you,
if
you
don't
feel
comfortable
doing
so
so
I
think
the
point
that
you
made
was
that
if
the
token
is
linked
to
some
system
of
record,
we
are
not
actually
tokenizing
and
I
guess
the
question
is:
why
do
you
think
that
it
is
the
case
because
what
we
are
saying
is
that
all
like
on-chain
token
are
just
linked
to
their
underlying
option
asset,
and
why
does
it
not
fit
the
description
of
tokenizing,
I'm
not
too
sure.
To
be
honest,
we
are
not
saying
they
are
dependent.
D
D
Of
the
factoring,
what
your
creating
a
token,
which
is
based
on
a
financial
instrument
which
is
based
on
an
invoice
and
the
added
value
for
a
factoring
company,
is
that
because
it's
part
of
the
work
group
it's
able
to
it's
able
to
to
have
a
verified
transaction
between
the
two
parties.
D
One
of
him
is
then
asking
for
for
money
based
on
that
transaction
right
and
then
the
tokenization
is
an
extension
to
that,
where
the
factoring
company,
for
example,
tokenizes
in
itself
in
a
sense
that
it
gives
the
its
own
investors
possibility
to
participate.
D
B
A
B
B
So
in
some
use
case
there
must
be
a
liquidity
and
the
token
should
be
able
to
be
tradable.
You
know
very
easily
in
other
cases,
it
might
not
be
the
case
and
the
point
here
and
that's
the
point
that
ognen
was
making
is
that
different
standouts
can
cater
to
different
requirements
and
we
should
not
impose
one
token
standard.
B
In
the
same
case,
we
can
say
that
we
can
have
nft
for
art,
but
we
can
have
you
know
many
different
types
for
other
like
we
can
actually
table
tokens
for
other
use
cases.
So
so
another
question:
how
can
an
investor
be
sure
that
every
token
has
an
underlying
physical
assets-
and
this
is
all
of
the
value
of
baseline
right
baseline-
ensures
that
the
parties
involved
in
the
war
group?
B
If
we
speak
in
the
tip
for
invoice
that
the
invoice
has
been
it's
a
kind
of
validated
and
certified
that
the
consistency
is
there
between
party
a
the
supplier
and
party
b,
my
buyer,
so
this
invoice
exists
and
now
we
are
seeing
that
there
is
a
third
party,
the
invoice
factoring,
which
also
has
their
set
of
all
business
rules
subsequent
to
this
process,
but
still
link.
So
all
of
those
proof,
part
of
the
same
workflow
are
each
very,
very
verifiable.
It's
not
one
big
proof
that
is
on
the
blockchain.
B
You
can't
verify
each
step
of
the
process,
so
if
you
are
able
to
do
so,
you
can
track
back
and
verify
that
this
token
is
linked
to
a
very
verifiable
asset
and
all
the
tokenization
process
does
not
is
not
independent
of
the
legal
obligation
of
each
company
that
still
exists.
This
is
still
that's
why
I
mentioned
business
as
usual,
so
we
are
really
talking
about
cooperation,
small
big
companies
operating
under
a
regulatory
and
legal
framework
that
does
not
go
away
because
we
are
adding
tokenization
to
their
process.
B
D
You
would
call
the
buyer
to
verify
that
there
was
the
invoice
or
you
would
you
would
do
whatever
method.
You
need
to
do
to
verify
that
here
what
you
get
with
baseline
is
that
because
they
are
using
the
because
they
are
part
of
the
work
group
that
has
a
specific
circuit
involved.
You
know
that
if
there
is
a
status
of
the
invoice
in
the
supplier
system
which
is
set
to
verified,
you
know
that
the
same
thing
is
in
the
buyer
system.
So
then
the
factoring
company
just
has
another
level
of
of
of
verification.
D
Right
that
there
is,
you
could
still
have
fraud.
Of
course
you
cannot
be
sure.
Never
basically,
but
you
have
another
level
of
verification,
and
same
goes
for
the
investor.
If,
for
example,
it
is
an
institutional
investor
that
wants
to
invest
into
bulk
of
invoices
financial
instruments,
it
could
be
in
their
interest
that
they
join
a
work
group
with
a
factoring
company
or
a
nurse
financing
platform
where
they
can
see
the
proofs
of
the
finance
of
the.
A
A
D
B
Exactly
and
that
led
nicely
to
deployment
step,
we
could
say
that
the
first
step
be
before
the
tokenization.
Well,
the
first
step
of
the
tokenization
process
is
to
fi
is
to
verify
the
identity
of
the
entity
that
is
triggering
that
process.
So
we
want
to
ensure
that
whoever
triggers
the
tokenization
process
is
a
rightful
owner
of
that
asset.
Does
that
make
sense?
So
I
think
it
also
addresses
one
of
the
points
on.
B
The
I
think
we
have
also
addressed
the
point
about
different
system
of
record
may
impose
their
own
local
interpretation
and
the
point
is
no,
with
baseline,
the
the
rules,
the
verification
rules
and
the
business
logic
is
agree.
Those
are
agreed
pre-deployment,
so
we
are
sure
that
the
different
participants
of
the
raw
group
are
aligned
and
in
sync
they
don't
have
different.
B
We
don't
have
different
interpretation,
we
all
agree
and
we
all
sign
off
on
the
business
rules
and
what
will
be
validated
and
when
and
what
does
it
mean
for
this
thing
to
be
validated
and
verifiable
and
then
verified
so
yeah.
So
if
we
go
back
here
so
the
deployment
step
and
that's
the
one
I
mentioned
is
before
tokenizing
the
the
asset
verify.
J
J
Is
joel
speaking,
sorry
for
being
so
quiet
all
throughout?
I
was
actually
trying
to
fix
a
computer
issue
on
on
the
side,
but
I
followed
the
conversation
just
now
and
I
I
just
wanted
to
add
some
food
for
thought
and
this
might
sound
like
rambling.
J
So
apologize
apologies
for
that
as
well,
but
when,
if
you,
if
you
look
at
the
current
world
and
how
proof
of
ownership
is
registered,
for
example,
when
you
have
a
house
I
I
I
live
in
switzerland,
zurich,
so
I
don't
quite
know
how
it
works
in
the
rest
of
the
world,
but
when
it,
when
you
have,
whenever
you
buy
a
house
or
whenever
you
transfer
the
ownership
of
a
house
the
only
way
you
can
actually
prove
that
you
own
that
house,
if
you
have
a
notary
scout
counter
sign
that
right.
J
So
I
was
always
wondering
when
it
comes
to
these
tokenized
physical
assets
or
tokenized,
artworks
or
tokenized
real
estates.
If
we
could
integrate
a
leak,
the
legal
component
or
the
let's
say
the
notary
that
we
already
have,
and
they
would
counter
sign
the
the
ownership
change,
then
you
would
have
the
same.
J
I
would
say
the
same
confidence
that
the
tokenized
item
that
you
are
looking
at
is
actually
owned
by
the
person
that
it
claims
to
be
owned
by,
and
that
could
already
add
this,
like
layer
of
confidence,
of
course
we're
adding
in
a
somewhat
of
a
waiting
time,
because
the
notary
has
to
be
involved
and
he
has
to
counter
sign
it,
and
it
has
to
be
part
of
the
business
process.
But
we
can
definitely
replicate
that
source
of
trust
with
a
tokenized
asset,
and
that
would,
from
my
perspective,
would
be
really
interesting.
J
D
If
I
can
add
to
that,
so
when
you're
talking,
for
example,
about
invoice
financing,
you
don't
want
to
have
the
ownership
public
in
any
sense,
because
you're
revealing
a
business
transaction,
that's
happening.
But
if
you're
talking
about
owning
real
estate
or
something
like
that
there.
That's.
That
would
be
a
must
right,
because
that's
the
proof
that
that
you
actually
own
in
the
physical
world,
an
asset
and
one
thing
where
baseline
could
actually
be
really
useful.
D
The
protocol
is
that
the
regulatory
institutions
could,
for
a
specific,
let's
say,
for
a
specific
market
or
for
a
specific
business
in
a
market
they
could
propose
a
set
of
work
groups
that
you
need
to
be
part
of,
and
they
could
devise
the
circuits
that
are
part
of
that
work
group.
D
So,
in
that
sense,
whoever
wants
to
deal
with
selling
real
estate
would
need
to
be
part
of
a
work
group
and
the
regulatory
institutions
would
set
up
what
are
the
business
rules
in
that
regroup
and,
in
that
sense,
just
being
part
of
the
work
group
for
a
market
entity
would
mean
that
it
has
to
comply
with
certain
regulatory.
D
The
practices
such
as
the
the
real
estate
being
authorized.
J
Okay,
so
that
is
designed
for,
but
you
just
mentioned
with
certain
things
you
don't
want
you
want,
you
don't
want
it
to
be
public,
calling
who
owns
the
asset,
and
I
guess
with
a
high
ticket
items.
That's
particularly
interesting
because
you
don't
want
to
get
robbed.
I
guess,
but.
D
Yeah,
but
you
would
you
would
sort
of
interrupt
you
would
in
an
innova
group.
You
would
like
to
share
that
information,
so
the
supplier
and
the
buyer
in
the
tokenization
process
of
anyways
they,
the
interest
of
the
supplier,
is
that
it
gives
all
the
information
to
the
company
that
is
going
to
finance
its
invoices
for
the
sake
of
credit
risk
and
so
on.
So
in
the
work
group,
the
information
should
be
shared,
but
outside
of
the
work
group,
when
you
do
the
tokenization
towards
the
public,
you
don't
want
to
share
any
sensitive
information.
D
For
example,
it
could
mean
that
the
asset
value
in
the
system
of
records-
let's
say
10
000
francs-
needs
to
be
the
same
as
the
number
of
tokens
that
are
minted
10
000
amounts
or
tokens.
So
this
is
where
you,
where
you
connect
the
outside
world
or
the
token
with
the
baseline
asset
inside
of
our
group,.
J
B
Which
clearly
there
is
so
to
go
back
about
having
a
second
war
group
for
regulatory
purposes
and
whatever
proof
that
come
as
a
result
of
a
workflow
being
executed
in
this
work
group
can
be
verified
by
another
war
group,
so
that
step
here
of
verification
of
asset
ownership,
as
ognen
said,
is
we
will
have
one
wall
group
with
verification
and
then
as
part
of
the
second
wall
group,
which
involves
supplier,
buyer
and
factoring
company.
For
example.
We
could
link
to
that
proof
to
say
now.
K
Whatever
ownership,
but
also
like
for
the
project
financing
use
case,
you're
going
to
want
to
ver
validate
that
comments
have
been
provided.
You
know
environmental
comments
and
other
issues
of
project
financing.
So.
B
G
G
D
I
don't,
I
think,
that
small
asset,
once
you
have
a
confirmation
in
the
blockchain,
you
would
return
that
information
back
to
the
you
would
store
that
information
in
the
asset
in
the
system
of
records
propagate
that
to
all
the
parties
involved.
That
propagation
of
state
would
be
the
last
step
in
the
deployment.
If
it's
successful.
B
So
when
we
discuss
about
well
we'll
get
a
bit
more
technical
now,
but
technical
architecture
and
implementation
options,
which
is
somehow
linked
to
yeah,
took
instant
art
selection
as
well.
B
D
D
There
is
actually
an
interesting
use
case
there
in
in
exactly
in
factoring
where
you
have
the
issue
that
the
company
could
request
factoring
in
the
same
time,
for
the
same
invoice
to
multiple
different
factoring
companies
and
then
duplication,
check
or
a
work
group
that
shared
the
manufacturing
companies
where
they
verified
the
hashes
of
the
invoices
that
are
being
submitted
just
to
check.
If
there
is
a
potential
fraud.
That's
a
good.
B
B
I
think
you
are
trying
to
make
a
point
since
a
moment,
but
I'm
not
too.
B
D
So
you're
not
replicating
the
existing
dependencies,
you're
you're
working
on
the
added
value,
which
was
provided
by
having
a
single
source
of
truth
between
different
multiple
source,
separate
silos
of
truth.
So
to
say
right
so
because
the
because
the
two
parties,
for
example,
use
the
open
public
shared
database
to
say
the
state
between
our
system
is
leveled.
A
D
On
with
that
value,
so
it's
not
that
your
replicating
the
dependencies.
You
are
tokenizing,
a
value
which
was
created
out
of
the
baseline
process,
in
this
case
just
aligning
two
systems
of
records,
which
gives
you
kind
of
a
proof
that
the
transaction
happened.
Not
sure.
If
I
addressed
your
question
but.
B
So
sorry,
if,
if
we
didn't
but
yeah,
that's
the
best
we'll
be
able
to
do,
I
think
so
in
terms
in
terms
of
the
technical
architecture,
so
we
definitely
will
have
a
option,
tokenization
model,
so
a
token
edition
platform.
Even
then,
we
have
to
think
about
a
smart
contract
architecture.
B
Could
it
be
a
case
that
we
have
a
small
contract?
Well,
the
tokens
just
mean
deploy
themselves.
So
it's
not.
We
have
a
contract
like
a
token
factory.
If
that
makes
sense,
where
are
we?
Okay,
yeah
technical.
B
Yep,
so
what
do
we
think
about
this
idea?
So
how
could
that
be
implemented
in
the
context
of
baseline?
So
as
a
reminder,
there
is
a
shield
contract
that
is
in
charge
of
you,
know,
verifying
and
well
the
the
merkel
tree
lives
within
the
chill
contract.
So
all
the
proofs
is
basically
a
proof,
is
a
leaf
within
the
shared
contract,
etc,
etc.
We
also
have
all
registry
contracts
that
basically
capture
all
the
participants
within
a
given
wall
group
and
we
have
the
verifier
contract
that
interacts
with
their
knowledge
package
as
well.
B
L
So
I
was
in
the
talk
earlier
and
I
think
right
now,
baseline
is
leveraging
nightfall,
but
I
might
be
wrong
in
terms
of
like
the
very
fire
contract
the
shield
contract
and
merkle
tree.
They
were
talking
about.
You
know
their
ziki
snog
versus
ziki,
stark
and
kind
of
being
a
zero
knowledge
proof
independent
right,
so
there
could
be
different
different
shield
contract
or
it
could
be
modular
right
where
the
provenance
and
the
minting
process
could
would
not
be
nightfall
dependent.
The
way
that
it
is
right
now.
L
The
only
check
would
be
that
zero
knowledge
has
been
applied
and
the
minting
would
be
or
like
the
the
the
tokenization
would
be
in
accordance
with
what
baseline
can
accept.
Type
of
thing.
B
B
That
holds
the
proof
of
all
the
baseline
activities
as
a
ensuring
that
two
two
system
of
records
I've
been
maintaining
a
state
of
consistency
or
any
of
the
things
that
we
want
to
check
and
we
have
what
we
can.
Can
we
call
it
the
token
factory
contract.
I
don't
know
if
that's
right.
B
I
do
think
that
this
is
a
use
case
agnostic
and
so
that
could
potentially
work.
D
D
A
D
Example,
you
have
the
privacy
service,
which
is
a
part
of
the
baseline
infrastructure,
so
to
say
that
deals
with
the
validation,
the
proofs
and
you
could
have
a
tokenization
service
or
that,
for
example,
implements
the
uses.
The
net
remind
client
or
whichever
client,
to
to
talk
to
the
blockchain
and
to
actually
perform
deployment.
B
Yeah,
that
makes
sense,
maybe
we
can
think
about
the
advantages
in
terms
of
both
security
risk
and
the
disadvantages
of
both.
I
mean
there
clear.
There
is
a
clear
advantage
to
have
a
tokenization
service
as
part
of
the
baseline
stack.
D
The
question,
for
example,
with
the
multi-token
contract
standard
1155,
the
idea
there
is
that
you
once
you
just
once
deployed
a
contract
and
every
other
token
creation
is
actually
just
a
function
call
and
there
you
you
would
not
need
you
just
would
have
one
contract.
That's
always
there
and
right
you
just
you
just
trigger
a
function,
call
to
to
meet
new
ones.
B
A
D
You
can
talk
to
to
to
fetch
to
fetch
the
proof
and
verified
it
against
the
the
the
contract
on
chain.
Just
before
doing
the
minting
or
something
like
that,
I'm
talking
out
of
my
head
not
sure
about
okay.
B
Yes,
yes,
which
is
yeah
it's
the
purpose
of
so
we
have
our
then
run
a
life
proof
that
could
verify
all
of
those
actually
that
if
we
have
the
business
logic
in
the
in
the
custom
circuit
or
whatever,
depending
on
the
use
case,
and
then
once
this
verification
is
done,
oops,
sorry
yeah,
why
is
he
doing
this?
B
B
That
then
mint
token
on
chain.
D
I
think
the
token
standard
selection
part
is
actually
covered
by
the
previous
by
the
previous
session
that
we
had.
So
it's
something
that
could
either
be
part
of.
You
would
have
it
as
a
part
of
a
work
step,
so
it
would
be
a
deploy
x,
y
z,
contract
standard
work,
step
right
or
it
could
be
something
which
is
a.
B
I
guess
a
question
about:
should
this
be
a
prerequisite
or
should
it
should
we
be
able
to
do
a
selection?
You
know
not
on
the
fly,
but
as
part
of
the
process
is
what
are
if
the
business
rules
and
what
we
need
to
verify
and
the
way
the
type
of
the
number
of
tokens
and
all
of
those
things
have
constraints
due
to
the
use
case.
This
should
be
a
prerequisite,
and
this
should
be
kind
of
embedded
like
predefined.
I
should
say
so
as
part
of
a
given
tokenization
process
for
a
specific
use
case.
B
The
choice
should
not
be
given
on
what
token
standard
to
use.
However,
in
other
use
cases-
and
it's
back
to
my
point-
I
think
so-
some
of
the
constraints
will
require
that
we
only
use,
or
we
only
rely
on
one
token
standard
right
and
we
should
not
have
the
choice.
Even
if
the
protocol
supports
many,
a
given
use
case
may
need
to
restrict
the
use
of
the
token
standard.
A
D
Yeah,
usually
the
use
case
would
at
least
from
what
I
can
see
right
now.
The
use
case
or
a
word
group
would
come
around
a
single
business
use
case
and
that
single
business
use
case
would
be
supported
by
a
single
token
standard,
which
is
the
best
fit
for
that.
So
it
is
something
that
is
predefined,
and
then
you
just
go
with
it
for
as
long
as
the
life
cycle
of
the
regroup.
B
Yeah,
so
in
comparison
to
what
we
discussed
earlier
about
the
tokenization
prerequisites,
a
lot
of
them
being
a
use
case
or
industry
specific,
but
maybe
not,
data
schema
privacy
and
security,
and
this
is
where
we
actually
need
to
create
or
investigate
further.
I
think
that,
based
on
the
conversation,
the
tokenization
process
actually
can
be
standardized.
B
So
as
long
as
first
deployment
step
is
verification,
verification
of
ownership,
verification
of
xyz,
verify
duplication,
check,
etc,
and
then
the
subsequent
you
know
steps
either
following
that
part
of
that
route.
So
I
think
I
will
already
capture
here
that
there
is
a
sense
that
the
tokenization
process,
when
it
comes
to
baselining,
can
be
standardized.
B
Okay,
that's
not
the
best,
but
anyway
we
do
with
what
we
have.
B
To
canonization
process
can
be
standardized,
so
we
are
saying
we
need
to
clearly
identify
identify
required
verification
steps
and
we
know
that
it
will
include
duplication.
Ownership
value,
as
must
have
other
can
be,
could
have
depending
on
use
case.
We
are
also
saying
that
okay
can
we
spend
okay?
Let
me
check
before
I
propose
this.
Oh,
we
have
10
minutes
left.
B
Can
we
discuss
for
10
minutes
advantage
and
disadvantage
of
those
two
approaches?
Please.
So
what
could
be
a
disadvantage
of
having
a
tokenization
service?
Does
it
remove
any
type
of
flexibility?
What
constraint
does
it
add
to
the
process?
I
would
say,
because
we
have
already
discussed
the
advantage
or
the
advantages
I
should
say.
Also.
We
have
questions
on
the
chat
as
well,
so
I
will
just
read
them.
B
So,
okay
from
a
standout
point
of
view,
in
the
same
way
we
are,
we
have
requirements
for
the
different
components,
so
messaging
service
privacy
service,
adding
a
tokenization
service
rather
than
having
a
token.
A
B
A
D
It
also
means
that,
if
you
go,
for
example,
for
the
tokenization
services,
you
might
lose
some
of
the
benefits
of
having
your
contract
deployment
being
publicly
available.
If,
for
whatever
reason,
that's
something
that's
that
should
be
publicly
available
and
provides
another
level
of
trust.
D
D
B
D
B
B
So
and
now
that
this
is
a
well
disadvantage
of
the
token
factoring
contract,
I
think
we
have
removed
this
story.
My
bad.
L
So
the
token
factory
would
just
point
to
existing
existing
contract
right.
It
wouldn't
be.
B
Contracts
right,
so
what
we
are
saying
is
this
can
be
used
for
self-minting
of
the
of
the
asset
of
the
tokens
right.
So
the
token
factory
will
have
all
the
required
function
that
and
the
chill
contract
will
trigger
the
tokenization
process.
G
B
Yes,
I
think
we
are
yeah,
we
have
six
minutes.
Is
there
anything
from
a
tokenization
process,
point
of
view
that
we
have
not
been
addressing,
and
that
is
like
a
high
level
of
coursing
that
we
actually
need
to
discuss.
I
think,
implement.
B
B
A
B
B
Sorry
I
mean
thing:
yeah
yeah,
so
we.
How
can
we
capture
this?
This
is
basically
saying:
how
would
that
work?
Ok,
so
the
contract.
B
G
D
Yeah,
that's
a
good
question:
if
you're,
if
you're
off
chain
talking
about
the
tokenization
service.
D
It
could
just
be
part
of
a
work
step
right,
so
it
waits
for
the
for
the
update
coming
from
the
blockchain
that
the
transaction
was
confirmed
and
then
based
on
that.
It
just
updates
the
system
of
record
if
it's
on
chain.
A
D
Contract
itself,
you
would
not
expect
it
to
it
could
just
throw
an
event
that
needs
to
be
listened
to
again
by
the
tokenization
service.
That
would
definitely
need
to
be
there,
but
it
just
depends
if
it's
going
to
do
the
actual
talking
deployments
or
not
or
just
going
to
do
everything
else
related
to
to
that
activity.
D
We
do
it
yeah.
You
would
expect
that
there
is
a
service
who
is
listening
for
blockchain
events
such
as
it's
the
same
thing
that
you
have
when
you,
when
the
shield
contract
stores
a
new
leaf,
a
state.
B
D
Yeah
there
is
an
event
thrown
and
you
listen.
Your
your
baseline
infrastructure
is
listening
for
that
event
and
based
on
that,
it
updates
the
system
of
record
of
the
initiator
and
then,
depending
on
the
work
step,
the
the
that
system
of
record
could
send
via
baseline
a
message
to
the
counterparty
saying.
B
Yeah,
so
we
are
saying
we
designed,
we
get
the
confirmation
where
that
our
token
has
been
successfully
deployed.
This
is
captured
by
our
baseline
stack,
which
then
sends
it
back
to
the
system
of
record,
which
updates
the
metadata
with
a
relevant
link
to
the
contract
and
the
token
id.
B
D
B
D
A
B
Okay,
I
actually,
I
want
to
show
a
question,
the
work
that
we
have
been
working
on
for
the
high
level
process.
Are
you
comfortable
if
I
show
that
now
to
just
put
back
some
context
about
the
invoice
factoring?
Yes,.
B
B
L
B
B
So
what
we
are
saying
here
seeing
here
my
bad,
is
a
process
walkthrough
for
what
we
have
been
discussing.
This
is
draft.
So,
as
you
can
see,
we
have
our
key
actors
involving
that.
Oh
sorry,
we
are
done
with
our
fourth,
it.
Okay,
you
don't
hear
it,
but
I
hear
it
very
loudly
on
my
side.
It
just
starts
screaming,
so
we
have
our
key
actors
of
our
raw
group.
So
we
have
our
supplier,
we
have
the
buyer,
we
have
the
factoring
company
and
we
have
the
credit
risk
assessment
company.
B
Alternatively,
we
may
or
may
not
have
the
tokenization
platform
as
well,
and
what
we
are
saying
is
that
once
a
supplier
takes
the
decision
to
factor
an
invoice,
the
record
it
says
invoice
itself
or
the
request
is
serialized.
Then
it
is
sent
to
the
so
the
message
messenger
service
of
the
baseline
stack.
So,
as
a
reminder,
we
have
messenger
service,
their
knowledge
service,
privacy,
no
sorry,
privacy
service,
which
is
a
zero
knowledge
service,
etc
sends
a
request
to
the
factoring
company.
B
So,
as
you
can
see,
the
factory
company
has
its
own
baseline
stack
and
the
way
the
protocol
has
been
designed.
It
doesn't
need
to
be
the
same
stack
because
the
api
and
everything
should
be
interoperable,
so
two
companies
providing
baseline
services
or
baseline
products
will
use
the
same
interfaces,
so
they
will
be
able
to
talk
to
one
another.
B
B
Exactly
so,
and
similarly
for
the
messaging
service,
there
is
no
prescription
that
you
have
to
use
nuts
or
I
remember,
radish34,
use
whisper.
You
don't
have
to.
B
B
Kind
of
good
send
a
message
to
the
system
of
record.
So
assuming
this
is
your
psap
assuming
this
is,
I
don't
know
crm
salesforce,
so
the
the
factoring
company
deposit,
the
the
invoice
into
their
own
system
of
record
and
then
through
an
api,
can
request
a
credit
assessment
to
be
provided
by
a
credit
risk
assessment
company.
B
There
is
an
alternative
where
we
say:
oh,
can
we
baseline
even
with
a
credit
risk
assessment
company?
You
can
baseline
with
any
party
as
long
as
they
are
part
of
the
raw
group.
So
if
there
is
already
this
infrastructure
in
place,
this
could
be
a
totally
viable
implementation
option.
Baseline
link
could
also
be
a
viable
implementation
option,
so
the
credit
risk
company
sent
back
the
result
to
the
factoring
company.
B
B
The
happy
path
is
that
I
inform
my
supplier
that
needs
to
inform
basically
the
buyer,
that
now
you
need
to
update
your
payment
terms,
because
the
invoice
has
been
sold
to
a
factoring
company
only
when
the
factoring
company
receives
acknowledgement,
for
example,
from
the
buyer,
or
even,
as
you
can
see
here,
the
buyer
control
updates.
So
the
buyer
has
its
own
baseline
stack
again.
So
all
of
the
three
party
involved
in
the
war
group
need
to
have
their
own
baseline
stack.
B
Then
the
factoring
company,
after
receiving
the
confirmation
that
payment
terms
have
been
updated.
So
now
I
am
entitled
to
receive
payment
for
the
invoice.
Then
they
can
trigger
the
tokenization
process
and
what
we
have
been
discussing
over
the
last
two
sessions
are:
how
does
that
process
look
like?
What
is
the
prerequisite
to
trigger
this?
What
are
the
token
creation
parameters,
etc,
etc?
So
I
hope
it
helps.
This
is
just
to
give
you
like
a
bit
of
the
background
behind
the
the
track.
B
B
B
B
B
J
It's
okay,
yes,
but
one
thing
so
me
and
mr
perry
here
in
the
chat,
did
have
actually
a
pretty
interesting
discussion
whenever
you
know
whenever
we
represent
the
things
of
value
in
terms
of
tokens
and
then
we
have
to
assign
certain
business
logic
to
that
token.
So
whenever
it
changes
that
the
value
is
also
updated,
potentially
and
but,
however,
over
time,
things
of
value
and
the
things
that
impact
it
can
change.
J
Need
to
be
able
to
upgrade
that
circuit,
according
to
those
changes,
did
baseline
already
try
to
architect
for
these
upgrades
in
the
circuit
logic
and
how
is
that
upgrade
structured
or
is
there
also
a
facilitation
of
having
a
community
governed
upgrade
of
that
circuit
structure?.
B
So
I
will
take
that
one
but
ognen.
Please
correct
me
if
I'm
wrong,
so
the
way
it
works
is
prior
to
executing
a
workflow.
All
the
business
logic
should
be
agreed
and
defined
by
all
defined
and
agreed
by
all
party,
so
either
there
will
be
a
generic
circuit
or
customs
most
likely
at
that
point
to
be
a
very
custom
zk
circuit.
So
your
question
is:
how
do
we
handle
upgrade
of
that
that
circuit?
So
if
business
rules
are
changing,
the
logic
would
be
that
all
parties
need
to
come
together.
B
A
B
D
Kyle
and
kartik
would
be
great
for
for
answering
this.
What
I
know
so
far,
I
I
don't
think
this
case
was
handled.
Currently,
the
idea
with
the
privacy
service
that's
being
implemented
at
the
moment
and
designed
and
implemented,
is
that
you,
as
an
initiator
of
a
work
group,
could
push
a
specific
set
of
circuits
for
all
the
participants.
D
I
guess
yes,
that
you
would,
you
would
have
a
state
until
sometime
and
then
you
would
have
a
new
new
rules
how
to
how
to
govern
or
how
to
achieve
which
business
rules
needs
to
be
applied
from
now
on
to
these
specific
assets.
But
it
could
be
hard
to
retractively
try
to
fit
already
baseline
assets
with
a
new
business
rule
right,
because
it's
actually
it
could
be
impossible.
D
D
I
guess
either
from
the
initiator
of
the
group,
for
example,
if
it's
a
regulatory
institution
or
through
some
form
of
agreement,
this
would
update
the
circuits
for
in
each
and
every
baseline
implementation
of
every
participant,
and
then
the
new
rules
would
be
involved,
but
I
cannot
tell
more
than
that
that
that's
really
just
high
level
and
I
think
the
work
there
is
not
progressed
too
much.
So
that's
one.
That's
a
good
point
for,
if
you're
interested
into
that
in
that
and
can
support
there.
D
That
would
be,
I
guess,
great
help
if
you
want
to
get
more
information
about
that,
the
best
persons
are
kyle,
thomas
or
or
kartik
solid,
purim.
B
Definitely
the
topic
of
debasing
and
re-basing.
It's
it's
linked,
because,
while
you
are
speaking,
I
was
thinking
if
I
have
a
new
circuit
and
some
of
my
records
have
been
baseline.
Do
I
just
rebase
line
based
on
the
new
business
rules
and
doing
like
or
from
a
this
should
be
straightforward,
because
one
record
can
be
subject
to
many
different
workflows
right
in
theory,
I
don't
see
why
this
could
not
be
done
now.
The
implication
will
be.
How
do
I
ensure
the
synchronization?
B
If
I
do
do
that
from
at
a
system
of
record
level?
What
is
the
impact
on
the
assets
that
have
already
been?
You
know
put
into
the
assets,
the
on-chain
assettories
that
have
already
been
created,
and
this
is,
I
guess,
what
we
wanted
to
capture
in
the
way
by
state
synchronization
between
the
option
asset
and
the
on-chain
asset.
So
we
can't
start
by
this.
I
think
ownership
is
very
important
as
well
transfer
of
ownership
and
things
like
that
so
yeah,
let's,
we
can
definitely
start
here
sure.
B
B
A
A
D
D
But
what
came
into
mind
during
the
discussion
coming
from
from
andreas
was
the
diamond
pattern,
which
is
a
pattern
for
deploying
or
having
a
contract
that
can
have
some
responsibility
that
can
be
modularly
exchanged.
Let's
say
so.
The
diamond
basically
holds
a
map
between
the
calls
or
its
external
functions
and
the
separate
contracts
that
are
going
to
perform
those
functions,
and
then
you
can
just
modularly
remove
or
exchange
functionality.
Just
by
changing
the
entry
in
a
map
or.
D
Yes,
something
like
that
and
diamond
pattern
supposes
that
there
is
just
that
one
contract
that
then
controls
a
full
set
of
contracts
that
are
that
are
below,
and
that
came
as
one
option
to
to
try
to
quickly.
Let's
say
quickly,
I
mean
more
efficiently
deal
with
with
these
kind
of
issues.
B
So
is
it
that
we
would
add
to
the
baseline
infrastructure
some
kind
of
maintenance
contract
if
we
can
cut
it
like
this?
That
would
follow
the
diamond
pattern
for.
A
A
D
D
It
could
serve
as
a
facade,
so
between
your
contracts
and,
for
example,
if
you
have
the
token
factory
contract
that
has
an
issue,
you
would
just
exchange
that
mapping
in
the
in
the
diamond
contract,
and
then
you
would
use
a
different
fund
further
on
for
for
deploying
for
deploying
the
contracts.
B
D
B
D
In
case
that
there
is
a
issue
or
a
need
for
for
an
upgrade
it
yeah,
it
further
complicates
the
implementation
in
the
beginning,
I
would
say,
but
later
on
could
later
on,
allow
for
for
easier
upgrading
and
it
would
be
necessary.
I
guess
only
for
specific
use
cases
where
you
really
go
with
a
lot
of
deployments.
A
lot
of
contracts.
G
B
Yes,
that
makes
sense.
Sorry,
I'm
just
catching
her,
because
there
was
some
conversation
happening
in
the
chat.
Oh,
okay,
it's
teaser.
A
B
I
was
trying
to
ensure
that
we
will
not
like
if
we
are
addressing
everybody's
concern,
but
I
think
we
are
all
good.
I
think
we
are
good
in
in
for
token
ownership
transfer,
so
we
did
say
that
this
would
be
part
of
the
potentially
sorry
token
standard
support.
So
we
need
to
ensure
that.
B
B
D
B
D
B
B
A
B
So
so
why
I
was
thinking
sorry,
I
was
thinking
about
the
legal
sorry
component
as
well
right,
which
is
like
from
a
business
point
of
view.
Whatever
happens,
there
is
a
reflection
of
changes
happening
option
right,
which
is
why
I
was
wondering
all
of
those
change
of
ownership
will
be
documented
and
by
formal
or
legal
documents.
B
First,
that's
what
I
was
trying
to
understand.
If
we
have,
if
we
define
business
rules
again,
those
can
be
baseline,
because
if
for
project
financing,
we
have
at
the
beginning
five
investors
and
for
phase
two
of
the
project,
I
don't
know
one
investor
withdraw,
because
this
is
allowed
within
their
close.
For
example,
it
means
that
this
document
itself,
that
was
baseline,
is
now
amended
and
now
updated
right.
B
Okay,
so
we
could
repeat
so:
let's
forget
about
implementation.
Let's,
let's
talk
about
business
as
usual.
There
is
a
project
with
many
parties
agreeing
to
finance
this
project.
There
are
many
phases
to
that
project.
It's.
It
is
not
said
that
all
of
those
parties
are
fully
committed
that
there
could
be
a
clause
where,
after
a
certain
phase
of
the
project,
I
can
remove
myself
as
a.
A
B
Right,
this
change
affects
previously
based
line
documents
right
or
we
don't
that
don't
they
are
just
like
amanda
amendment
or
other
things.
So
I
was
trying
to
understand
if
this
mechanism
is
managed
through
baselining
of
record
with
a
circuit.
If
there
is
a
change
x
y
z,
then
we
need
to
verify,
then
we
need
to
put
put
this
proof
on
chain.
What
is
the
implication
of
managing
ownership
of
the
token
like.
A
B
B
B
Yes,
yeah,
so
this
is
definitely
use
case
specific.
I
agree
with
you,
but
I
still
think
that
there
should
be
a
mechanism,
so
not
only
to
rely
on
this,
which
is
very
good,
but
that.
D
B
So
so
that's
what
I
was
trying
to
say
that
in
the
same
way
in
our
data
schema,
we
have
a
legal
entity
legal
address.
The
only
difference
is
that
if
there
is
single
ownership,
we'll
have
one
entry.
If
there
is
multi-ownership
for
each
entity,
we
will
have
either
it's
a
person
or
a
company
will
have
that
right.
So
there
is
a
direct
link
between
this
and
this
here.
Yep.
B
Yes,
yeah,
so
I
will
capture
here
that
what
we
really
need
is
a
definition
of
ownership
and
the
scope
of
that
ownership,
because
it
can
be.
You
know
we
approached
it
from
two
different
perspectives
and
both
are
valid.
So
when
we
conti
we
carry
on
the
work,
we
need
to
clearly
define
you
know
what
ownership
means
in
that
context
and
what
ownership
you
know
means
in
that
context
and
how
those
are
links
linked,
sorry,
so
define
and
defer.
B
B
Sheep,
I
should
just
say,
define.
B
B
D
Related
to
the
state
synchronization,
I
didn't
follow
fully.
The
question
was
the
circuits
right
and
the
other
topic
is
the:
how
do
we
there
is
a
change
in
let's
say
the
token
is
open
for
secondary
market
trading,
so
the
investor
sells,
and
there
is
a
change
in
the
ownership
that
needs
to
be
reflected
in
the
system
of
record
in
the
work
group.
So
how
would
how
would
we
handle
that?
How
would
we
synchronize
back
that
state.
A
B
B
For
ownership,
like
sorry
token
ownership.
D
I'm
I'm
not
thinking
just
about
ownership,
let's
say,
for
whatever
reason:
there
is
a
state
change.
In
the
token
that
needs
to
be
reflected
back
in
the
system
of
record
right,
somebody
burned
the
tokens.
So
now
you
have
less
of
them,
and
this
needs
to
be
reflected.
What
would
be
the
mechanism
to
to
send
that
back?
We
would
yeah.
We
probably
need
to
again.
D
B
B
It
will
be
better
to
have
this
captured.
I
mean
first,
you
have
to.
We
have
to
check
that
there
is
even
the
authorization
to
burn
the
token
right,
so
that
will
be
the
first
verification
step.
Is
the
person
requesting
or
triggering
yeah
yeah
to
output
that
so
this
sorry?
Where
would
you
put
that?
That's
not
only.
B
B
B
B
D
Right,
you
would
have
it
already
in
a
smart
contract,
meaning
that
these
are
the
business
rules
under
which
this
can
change.
So
coming
back
that
state
through
an
event
coming
back
to
the
system
of
record.
B
G
B
D
So
yeah
you
want
to
have
the
state
right
between
the
the
parties.
You
want
the
state
to
be
the
same,
and
if
there
is
a
functionality
in
the
token
that
enables
the
state
to
be
changed
outside
of
your
control,
for
whatever
reason
you
want
that
state
reflected
back
in
the
system
of
record
because
they
are
not
in
sync
anymore.
B
B
D
J
So
in
the
chat
I
had
a
conversation
with
some
of
some
of
the
other
participants,
and
one
thing
that
is
fairly
obvious
is
that
whenever
we
have
some
type
of
asset
represented
as
a
token
and
we
have
a
circuit
that
is
sort
of
governing
the
some
of
the
business
logic.
That
is
impacting
that
token.
J
M
Yeah,
there's
no
great
easter.
That's
a
that's
a
great
question.
I
mean
the
the
concept
of
an
upgradeable.
Smart
contract
is
sort
of
one
way
to
look
at
it.
The
nuances
around
upgrading,
upgrading
the
circuit
itself
is
something
that
I
personally
haven't
gotten
to.
Yet
I
think
it's
possible.
M
I
think
it's
possible
to
upgrade
it,
but
there's
probably
a
lot
of
a
lot
of
implications
there.
That,
essentially,
would
require
you
to
nullify.
M
You
would
probably
have
to
exit,
for
example,
the
the
like
the
older
version
of
the
the
the
proof.
It's
like
the
version
that
you're
that
you're
upgrading
from
I
don't
think
those
those
those
truths
would
be
valid
anymore.
M
Possibly
you
could
come
up
with
a
with
a
scheme,
though,
to
make
them
valid
in
another
context,
all
right,
tldr
like
it
needs
some
needs
some
research,
but.
A
M
Upgrade
you
can
upgrade
a
smart
contract,
so
I
think
I
think
it
can
be
done,
but
we're
not
you
know
we're
not
quite
there
yet.
J
See
well
when
I
mean
if
you
have,
we
also
spoke
about
the
diamond
pattern
and
to
have
upgradable
smart
contracts,
but
does
that
also
apply
to
circuits.
M
No
so
like
you,
the
diamond
pattern
will
apply
like
we'll
be
able
to
upgrade
the
shield
contract,
which
will
like
the
verifier
will
need
to
we'll
need
to
replace
the
verifier
in
the
shield
contract.
With
the
new
circuits
verifier,
that's
going
to
invalidate
all
of
the
previously
valid
proofs,
which
means
we
will
have
to
exit
those.
M
We
are
looking
at
exiting
we're
looking
at
how
to
exit
a
a
work
group,
for
example
like.
M
A
process
reaches
finality
how
you
might
exit
the
from
one
work
group
to
another.
We
are
looking
at
that
and
to
me
this
is
just
like
a
variation
on
that,
but
it's
complicated
it's
complicated.
I
think
it
will.
I
think
it
would
work.
Similarly
to
that
use
case,
though,
for
example,
when
I
what
I,
what
I
mean
by
exit,
is
a
business
process
is
completed
and
you
want
to
tokenize.
M
You
want
to
know
what,
like
you,
want
to
basically
mark
the
the
state
of
that
process,
that
workflow
is
finalized
and
then
take
the
proof
and
act.
Quote-Unquote
generate
an
exit
proof
that
wraps
all
of
the
the
previously
valid
proofs
that
have
been
quote
unquote,
exited
that
are
or
that
process
is
finalized
and
then
use
that
exit
proof
as
the
input
to
another
work
group.
The
circuit
on
another
work
group,
so
I
think
the
upgrade
like
upgrading
a
circuit
would
be
a
variation
of
that.
M
Kind
of
it
is
kind
of
a
fork,
but
you
you,
if
you
don't
have
a
way
to
like
market.
M
Now,
like
exiting,
is
sort
of
like
a
fork,
but
you
have
to
you
have
to
market
somehow
so
that
the
other
participants
can
recognize
it.
You
know
it's
it's
it's
easy
like
when
a
chain
forks,
you
know
it's
everyone.
No
one
really
sees
the
fork.
Everyone
just
thinks
the
chain
is
accurate,
but
you
know
I
mean
there's
two
chains,
but
in
this
case
of
like
there's
real
money
involved
on
a
tokenized
invoice,
for
example,
all
the
parties
need
to
you
need
to
know
like
deterministically,
that
one
has
been
exited
and
upgraded.
M
You
have
to
finalize
it
somehow,
which
is
to
me,
doable
in
the
context
of
what
we're
talking
about
here.
M
I
mean,
I
think,
the
diamond,
I
think,
you're
on
to
something
with
the
diamond
pattern.
I
mean
that's
something
that
we
need
to
do
immediately
and
it's
something
that
andreas
and
I
and
karthik
and
others
have
talked
through
already
john.
I
know
you
have
you
know
a
lot
of
good
insight
and
and
direction
there.
So,
if
you'd
like
to
help
with
that
initiative,
I
would
say
now
would
be
a
great
time.
M
The
shield,
the
shield
contract
itself
needs
to
implement
the
diamond
pattern.
The
work
group
shield
contract
yeah
because
each
workflow
will
be
each
workflow,
will
have
an
upgradable
verifier
contract
associated
with
it.
B
Okay,
because
we
have
thank
you,
carl
very
much,
all
this
20
minutes
left.
What
I
propose
is
that
we
go
through
what
we
have
discussed
and
we
either
agree
or
disagree
on
the
the
conclusions,
because
we
had
people
back
and
forth
and
some
people
are
since
the
very
beginning,
but
some
people
are
like
I
just
joined
now.
So
during
the
session,
the
three-hour
session
we
discussed,
tokenization,
prerequisite
tokenization
process
and
token
governance.
B
One
of
our
conclusions
for
the
tokenization
prerequisite
is
a
a
lot
of
those
requirements
will
be
use
case
specific
and
industry
dependent.
However,
we
definitely
need
to
spend
some
time
working
on
the
data
schema
and
metadata
so
field
or
key
data
points
such
as
legal
address,
legal
entity,
token
address
contract
reference
to
ocean
engine
token
ids.
B
Similarly,
on
authorization,
we
said
that
it
depends
on
the
case
of
invoice
financing
all
option.
The
data
should
remain
private.
However,
for
our
project
financing,
we
saw
that
investors
would
need
to
have
access
to
the
underlying
option
asset,
so
this
is
most
likely
to
be
a
use
case,
specific
same
forecast,
distribution
most
likely
to
be
used
specific.
B
However,
we
need
to
spend
some
time
really
looking
into
privacy
requirements,
security
requirements
which
are
most
likely
to
be
standardized
like
we
can
probably
standardize
those
so-
and
I
take
the
time
to
raise
them
that,
because
it
could
be
that
when
it
comes
to
post
summit
work,
including
the
acaton,
we
could
have
things
linked
to
the
linked
to
those
items.
B
So
yeah
we
take
notes
on
the
token
support
standard.
The
only
requirement
is
that
many
token
standards
must
be
supported.
It
will
be
use
case
specific
if
one
or
two,
no
one
or
more
token
standard
must
be
required.
So
here
we
cannot
specify,
as
part
of
the
baseline
standard,
that
we
cannot
dictate
what
token
standard
should
be
supported.
B
B
B
We
need
to
clarify
sorry
you.
We
need
to
clearly
identify
what
are
the
must
have
requirement
for
verification.
We
have
and
already
identified
asset
asset
ownership,
verification,
duplication
check
and
asset
value,
so
those
are,
the
three
must
have
everything
else
be
can
be
should
have
and
our
use
case
specific.
B
We
have
also
discussed
two
implementation
options,
either
having
a
chill
contract,
sending
a
call
to
the
token
factory
contract
to
trigger
the
where's,
the
tokenization
process,
basically
or
we
have
a
new
tokenization
service
as
part
of
the
baseline
stack,
where
we
will
have
the
privacy
service
sending
a
request
or
call
to
the
tokenization
service
to
mint
the
token,
and
then
we
will
update
basically
back
the
system
of
records.
D
Tokenization
service
is
probably
a
must
at
least
for
listening
to
on
train
events
and
reacting
to
them,
and
then
it's
only
a
question
if
it
should
also
take
deployment
responsibility
or
leave
that,
for
the
token
factory
contract.
B
J
J
B
If
something
fails
or
either
it's
fraud,
which
is,
we
can
never
bring
fraud
to
zero,
I
guess
an
example
could
be
a
supplier
sends
a
invoice
factoring
request
to
tokenization
company
a
factoring
company,
sorry
which
are
not
part
of
the
same
work
group,
so
they
cannot
check
between
them.
You
know
if
they
have
received
the
same
request.
B
B
Assuming
no,
no,
we
know
that
they
can
talk
and
it's
not
a
problem
if
they
can
talk,
because
we'll
have
one
work
group
with
all
the
factoring
companies
ensuring
that
there
is
only
one,
you
know
request
for
a
given
invoice.
However,
if
a
given
factoring
company
is
not
part
of
that
raw
group,
what
do
we
do?
I
guess
that's
a
question.
D
I
mean
it
can
even
be
further
simplified
that
you
could
have
a
bug
in
software
that
allows
for
another
initiation
of
tokenization
of
an
asset.
That's
already
been
tokenized
for
whatever
reason,
and
then
the
duplication
check
would
come
as
come
as
a
sanity
check
to
verify
that
this
thing
does
not
exist
based
on
some
predefined.
D
A
duplicate
that
duplicated
somebody
tries
to
tokenize
the
asset
once
again.
Well,.
M
Existence
of
the
the
protocol
would
have
to
be
set
up,
such
that
the
existence
of
an
exit
proof
indicates
that
the
that
it's
not
eligible
for
tokenization
like
the
workflow's
been
finalized
and
that
that
it's
basically
like
there's
a
bridge
has
been
established
between
that
workers
and
another
one.
D
Or
yeah,
if,
if
it
happens
in
parallel
right,
if
two
parties
could
try
to
initiate
tokenization
at
the
same
time
and
one
succeeds
first
and
the
update
for
that
is
still
not
there.
So
there
is
a
duplication
check
to
verify
in
this
small
amount
of
time.
If
there
is,
there
is
a
potential
issue,
it
would
just.
M
Proof
has
to
be
only
you
use,
it's
a
zero
knowledge
proof
right,
meaning
the
that
proof
can
only
be
used
by
one
by
one
work
group
by
one
other
work
group
like
the
exit
proof
itself
is
like
you
would
have
to
have,
given
the
you
would
have
to
have
given
the
the
private,
the
public
private
inputs
of
to
the
circuit,
to
the
exit
like
the
exit
circuit,
basically
to
multiple
parties,
which,
ultimately
you
know
there
would
there
have
to
be.
You
have
to
exit
it
to
a
single
to
one
other
work
group.
M
You
know
I
mean
like
if
you,
if
you
give
that,
if
you
give
if
it's
tried,
if
you
try
to
use
it
in
the
context
of
multiple
work,
groups
like
there
has
to
be
something
in
the
protocol
that
prevents
that.
D
J
A
J
Or
a
very
valuable
coin
for
coin
collectors,
and
someone
has
bought
a
fake
at
some
point.
But
it's
a
really
well
made
fake
and
now
two
of
these
exist
and
we're
both
tokenizing
it
and
for
some
reason,
we're
bypassing
this
duplication
check
because
it
seems
legit
and.
M
If
you
talk
about
the
coin,
the
baseline,
the
work
steps
are
the
work
steps
in
involved
in
that
are
signatures
from
the
manufacturer
or
what
or
you
know
or
the
or
the
or
like
the
art
or
like
the
appraiser
right,
some
trusted
group
or
consortium.
That's
like
yeah.
This
is
legit,
so.
J
When
one
works
accepted,
appraisers
and.
M
If
you
talk,
if
you
talk
about
invoicing,
it's
a
little
easier
in
the
context
of
invoicing
right,
because
every
single
step
in
the
process
of
invoicing,
if
you
keep
those
in
not
like
a
non-reputed,
if
you
keep
those
compliant
with
like
non-repudiation
of
claims,
you
can,
you
could
suggest
that,
like
the
is
legit
and
you
can,
you
can
tokenize
it
without
any
like
any
gotcha
like
there's,
not
an
extra
zero.
That's
been
answered
against
it,
like
everyone's
an
agreement
that,
like
the
invoice,
is
payable.
M
You
can
then
exit
that
invoice
into
d5,
for
example,
and
take
it
out
of
the
work
group
that
it
that
it
was
created
in
where
the
workflow
has
ended
and
send
it
across
the
you
know
across
the
you
know
the
network
somewhere
to
some
other
work
group.
Where
that
the
proof,
the
exit
proof
is
used
as
the
input
to
a
new
workflow
in
that
other
work
group,
which
involves
oh,
it
could
involve
anything.
M
You
know
from
a
bunch
of
different
work
groups
into
a
single
decentralized
exchange,
for
you
know,
bundle,
invoice,
tokens
right
and
if
you
like,
for
example,
if
you
know
the
location
in
the
the
merkle
tree
where,
where
the,
where
that,
where
that
invoice
has
been,
you
know
nullified
on
one
side
and
and
essentially
minted
on
the
on
the
other,
the
site
that
you're
actually
gonna,
you
know
be
able
to
use
it
as
a
financial
instrument.
I
think
there's,
that's
the
like.
M
There's
a
way
to
verify
the
proof
that
that
that
you
have
the
the
necessary
rights
to
use.
You
know
the
necessary.
You
know,
there's.
B
J
Yeah,
I
don't
know
whether
I
have
a
this
is
a
problem
in
my
head,
or
I
see
a
problem
coming
that
might
not
be
possible
because
of
the
way
that
it's
structured,
but
mistakes
happen,
and
it
could
be
that
we
have
an
asset
that
is
tokenized.
That
represents
one
physical
asset,
but
there
are
duplicates
of
that
on
chain
assets.
D
This
is
yeah
yeah.
This
is
something
that
would
need
to
be
taken
care
of,
based
on
the
use
case.
In
the
case
of
invoice
factoring,
you
would
expect
that
factoring
companies
who
are
who
have
the
interest
to
prevent
fraud
like
this
so
to
find
invoice
duplicates
that
they
would
have
between
themselves
and
their
system
of
record
a
work
group
which
is
baselining
exactly
the
hashes
of
the
invoice.
So
as
soon
as
there
is
a.
J
Voice
invoices
are
very
simple
examples
because
they
have
very
standardized
data
structures,
somewhat:
okay,
yeah.
What?
If
we
talking
artwork,
for
example,
how's
that
gonna
work?
If
somebody.
D
D
It's
if
it's
fake
artwork,
then
it's
not
something
that
should
be
sold
via
a
baseline
regroup
right
unless
you
have
some
way
to
digitize
the
physical
art
piece
and
then
and
then
hash
it
or
whatever,
and
then
verify
that
the
hash
is
unique.
B
So
it
will
it's
not.
We
are
no
longer
really
considering
a
fake
or,
I
would
say,
a
fraudulent
asset
as
a
duplicate.
We
are
really.
I
guess
this
point
here
was
really
tackling
real
duplication,
so
everything
that
falls
under
an
other
asset
which
is
a
counterfeit
or
whatever.
We
can
assume
that
the
legal
counterparty
which
is
supposed
to
provide
the
proof
that
this
asset
has
been
verified,
won't
be
able
to
provide
the
proof
for
the
second
asset.
B
Therefore,
we
remove
that
kind
of
fraudulent
activity
by
just
you
know
the
virtue
of
having
this
kind
of
legal
verification
step
on.
J
J
Me
and
I
think,
if
the
world,
if
the
world
wouldn't
go
crazy
at
some
point
with
these
artwork
pieces,
then
that's
going
to
work
forever.
However,
centralized
systems
like
ethereum
and
because
you
also
mentioned
d5
decentralized
exchanges
and
so
forth,
they're
truly
global
right.
So
when,
let's
just
let's
just
say,
we
have
the
mona
lisa
in
the
louvre,
and
someone
tokenized
this
and
it
it's
it's.
It
has
everything
it
needs.
J
K
M
A
M
B
Okay,
let's
carry
on
because
we
have
two
minutes
left,
so
I
think
okay
tokenization
process,
we
have
the
list.
Well,
not
least
we
have
verification
items.
We
also
discuss
possible
implementation
options.
A
B
B
Yeah,
yes,
or
and
or
it
depends
of
the
functionalities
of
the
tokenization
service,
it
could
also
be
responsible
or
for
the
deployment
of
the
token
contract.
If
we
choose
to
do
so
that
the
only
requirement
that
we
said
is
that
there
must
be
a
tokenization
service
now,
what
are
all
of
the
functionalities
of
that
tokenization
service?
We
have
not
sorry
define
that.
B
B
B
If
there
are
applicable
use
cases
or
not,
we
have
also
discussed
a
new
contract
that
could
be
added
following
the
diamond
pattern,
so
it
could
be
a
maintenance
contract
as
it
added
to
the
baseline
infrastructure,
which
will
be
fully
responsible
for
the
maintenance
of
all
the
other
contracts
small
contract
within
a
baseline
implementation.
M
Yeah,
I
think
it's
just
just
the
shield
contract.
The
the
work
group
shield
contract
is
the
diamond
pattern.
I
don't
know.
I
don't
think
that
it's.
I
think
that
there
could
be
an
use
case,
we're
having
another
shield
contract
somewhere,
but.
H
M
That,
if
we
just
replace
the
current
the
current
work
group,
basically,
we
need
to
create
a
a
work
group
shield
that
allows
multiple
instances
of
the
verifier
shield
pairs
that
we're
currently
deploying
to
be
made
upgradable.
In
that
context,.
B
B
A
B
D
B
D
A
G
B
Yeah,
yes,
yes,
and
I
think
that's
it.
We
have
done
our
three
hour
sessions.
I
was
very
productive
yep.
I
think
at
eye
level
we
have
made
like
we
have
good
starting
point.
I
think
we
got
some
highlight:
okay,
don't
go
there,
go
there,
don't
go
there.
Go
there
on
my
side.
I'm
definitely
happy
that
we
have
done
it
because
we
need.
We
know
where
to
start
the
work.
Actually
just
so
that's
that's.
D
B
M
Well,
yeah,
I
mean
the
whole
point.
The
whole
point
of
the
upgradeable
shield
is
being
able
to
upgrade
the
workflows.
M
B
M
Just
I
I
just
made
an
issue:
okay,.
B
M
B
Okay,
great
well,
thank
you,
everybody
for
joining
us
and
contributing
to
the
sessions
the
well.
This
will
stay
like
for
the
rest
of
the
summit,
so
feel
free
to
pop.
In
as
you
want,
you
have
access.
So
just
as
a
reminder,
if
you
go
to
the
slide
section,
this
is
where
you
will
find
the
link
to
the
mind
map.
Also
you
can
find
in
the
notes,
so
you
can
access
the
map
map
and
you
may
download
it
or
I
don't
know.
I
think
you
can
do
that,
I'm
not
too
sure
and
that's
it.