►
From YouTube: CasperLabs Community Call
Description
Rewards Distribution presentation & status update.
A
Excellent
so
good
morning,
good
day,
good
evening
to
everyone,
thanks
for
dialing
in
I'm,
going
to
provide
a
quick
update
for
the
community
on
our
engineering
progress
and
then
Alex
I'm,
going
to
walk
through
our
road
map
as
well,
and
then
Alex
will
talk
a
little
bit
more
about
economics
for
all
the
blockchain.
So
we'll
share
a
little
bit
more
about
our
thinking.
A
Let's
see
so,
we
are
currently
working
on
node
dot.
Twelve
note
11
was
released
and
the
dead
net
was
updated
on
16
January
last
week,
and
we
also
ran
a
weekly
workshop
with
the
code,
making
sure
that
everything
was
good
and
our
current
focus
continues
to
be
implementing
the
final
production
version
of
the
protocol.
With
right
now,
we're
focused
on
arrows
with
fixed
rounds,
fixed
length
rounds
and
a
fork
choice.
Rule
we're
also
doing
a
lot
of
work
in
the
smart
contracting
portion
of
the
execution
engine.
We
consider
this
to
be
a
really
important
thing.
A
Feature
of
our
platform
is
how
powerful
the
smart
contracting
engine
is
and
we're
also
getting
ready
for
test
net
or
alpha
test
net
end
of
March.
So,
let's
dive
in
a
little
bit
more
on
consensus,
we
are
building
in
the
prototype,
so
we've
got
to
work
streets
going,
we've
got
a
prototyping
stream,
that's
running
ahead
and
then
we've
got
a
production
code,
implementation,
that's
taking
the
prototype
and
writing
production
code.
A
So
a
coach
is
focused
on
building
the
production
code
in
Scala
and
he
is
working
on
building
highways
with
era's
presently
the
Aeron
manager
and
the
switch
blocks
so
going
from
one
arrow
to
the
next
era
and
then
leaders
within
the
arrows.
That's
what
its
current
focuses
and
then
inside
of
the
arrows
you'll
add
the
rounds.
A
We
have
some
ideas,
but
we
don't
actually
know,
and
so
we're
gonna
want
to
get
that
information
right
away.
So
that's
like
two
parallel
processes
around
or
three
rather
forgetting
protocol.
You
know
the
highway
protocol
done
we're
also
working
on
the
research
side,
we're
building
a
simulator,
but
this
enables
us
to
run
forward
in
time.
A
So
the
idea
is
that
we
should
be
able
to
implement
the
production
version
of
the
code
either
by
dropping
it
in
directly,
because
the
simulator
is
also
written
in
Scala
or
taking
what
was
implemented
production
implementing
it
in
this
in
the
simulator
and
then
you
know
fast-forwarding
through
time
right
many
years
to
see
what
happens
in
the
end
of
the
protocol.
Our
goal
is
that
we
get
this
to
this
Nash
equilibrium
of
you
know
secured
by
economics
where
the
protocols
it
kind
of
flexes
us
as
things
grow
and
change
right.
A
We're
also
doing
some
research
around
spam
protection,
and
so
this
is
how
validators
are
protected.
In
the
event,
somebody
tries
to
ddos
the
network.
So
what
does
spam
protection?
Look
like?
What's
the
user
experience
when
you
know
for
this,
what
is
it
one
of
the
changes,
the
protocol,
etc,
etc?
So,
there's
a
good
amount
of
work
were
working
on
with
Daniel
Caine
around
spam
protection.
So
try
to
understand
what
are
the
problems
we
need
to
solve.
A
There
we're
also
building
a
fork,
choice,
era
and
highway,
and
then
a
test
framework
and
contract
FFI
to
go
along
with
that.
We're
updating,
equivocations
detector,
to
check
ballot
equivocations
and
then
so.
This
is
the
different
of
ballots
and
blocks.
If
you
don't
have
a
block
to
propose
you
send
a
ballot
and
the
ballots
a
lot
smaller.
So
as
the
network
expands
out
to
a
thousand
validators
downloading,
all
those
ballots
could
potentially
become
very
expensive
to
the
leader,
so
we're
trying
to
make
the
ballots
as
small
as
possible.
A
Similarly,
they
were
also
looking
at
block
size
to
an
optimization
as
to
make
the
block
smaller
to
write
so
doing
a
installation
of
a
new
contract
will
be
more
expensive
for
the
network
visa
via
doing
an
invocation
of
an
existing
contract
right.
The
block
size
is
very
significant,
and
so
the
goal
is
to
one
keep
the
block
sizes
as
small
as
possible.
This
enables
better
performance
throughout
the
network
for
obvious
reasons
and
then
also
less
expense
for
the
for
the
node
node
users
as
well.
A
For
the
actual
end
users,
we're
testing
the
library
for
contract
developers.
For
those
of
you
not
aware
in
node
12
we're
going
to
be
releasing
a
contract
software
development
kit,
our
contracts,
sdk
that
will
include
a
runtime.
So
what's
really
cool
about
this
is
developers
can
will
open
up
a
Russ
to
like
project
inside
that
Russ
like
project,
you
will
have
an
instance
of
the
contract.
Sdk
runtime
you'll
have
all
your
sample
code.
A
You
will
also
have
documentation
available
to
you,
so
this
will
provide
a
very
nice
integrated
mechanism
for
contract
developers
to
write
and
test
their
contracts
directly
in
the
execution
engine.
So
you
don't
need
a
node
to
for
contract
development.
Of
course,
you
can
spin
up
a
three
node
network
very
easily
using
docker
and
then
deploy
your
contract
to
a
local,
duct
or
network
and
observe
how
your
contract
will
behave
on
the
network.
A
You
can
observe
how
you
would
do
queries
against
the
graph
interface
and
so
on
and
so
forth,
but
this
makes
it
very
very
easy
for
support
contract
development
in
tandem
with
that,
the
team
is
also
building
assembly.
Script.
Support
we're
very
excited
about
this.
So,
by
the
time
we
hit
our
alpha
test
net,
we
will
have
support
for
assembly
script,
which
is
a
flavor
of
typescript
you'll,
see
other
blockchain
projects,
calling
it
typescript
support.
It's
really
assembly
script
support.
A
There
are
some
differences
between
a
subway
script
and
typescript,
but
very
excited
to
offer
this,
and
we
will
also
be
offering
an
in-browser
IDE
that
will
be
coming
hopefully
by
the
node
14
timeframe.
If
can
pull
it
in
a
node
13
with
beta
test
that
that
would
be
really
sweet,
but
I
suspect
it
may
be
node
14,
but
it's
it's
really
using
the
web
assembly.
You
know
browser
based,
plugin
and
we'll
be
adding
that
to
the
clarity
block.
Explorer
you'll
see
the
assembly
script.
A
Work
come
in
right
now,
when
you
try
to
build
the
execution
engine,
you'll
see,
there's
a
dependency
for
NPM
and
that's
all
the
assembly
skip
work,
that's
being
done
on
the
node,
we're
doing
very
little
work
on
the
node
right
now
we're
adding
some
more
relationships
to
graph
QL,
making
that
interface
a
little
bit
richer
for
end-users
and
we've
got
the
sequential
in
power
block.
We've
got
some
work,
we're
doing
there
on
a
branch
to
see
how
sequential
and
parallel
blocks
will
be
executed
on
the
network.
For
those
of
you
are
not
aware.
A
Highway
protocol
has
the
capability
to
be
a
fully
concurrent
block
chain,
because
you
could,
theoretically
have
multiple
block
proposers
in
each
round.
Our
first
round,
our
first
implementation
of
Hiva,
will
have
a
single
leader,
but
we
believe
we
can
soften
this
constraint
and
have
multiple
leaders
without
breaking
the
liveness
proof.
So
this
is
something
that
we're
going
to
be
investigating
as
well
test
an
SRE
we're
looking
at
dev
net
security,
so
we're
hardening
the
definite
and
hardening
the
clarity
Explorer
in
preparation
for
a
test
net.
A
We're
also
like
I,
said
optimizing
CI,
so
it's
faster
and
building
large-scale
test
beds
right
now,
using
ansible
and
terraform
that
helps
us
self-service
entire
networks.
This
is
to
enable
a
coach
and
Mateos
and
Michael
and
andreas
that
are
doing
the
consensus
implementation
too
rapidly
it
basically,
you
know,
deploy,
fix
and
and
patch
right,
so
they
can
quickly
test
their
changes
on
an
entire
network.
A
On
the
economic
side,
we're
doing
the
design
of
compound
computation
storage,
bandwidth
pricing,
so
we're
looking
at
what
transactions
are
going
to
cost
we're.
Also
looking
at
spam
protection
in
collaboration
with
the
other
research
team,
we're
mocking
up
the
reward
distribution,
so
we're
going
to
do
a
mock
of
what
rewards
distribution
looks
like
for
those
of
you
not
aware
validators.
Our
rewards
are
throttled
by
liveness
failures.
So
if
your
node
happens
to
go
offline
and
doesn't
participate
in
certain
number
of
rounds,
your
rewards
will
be
throttled
for
less
participation.
A
That's
how
we
are
incentivizing
validators
to
remain
active
in
the
protocol,
we're
also
working
on
the
transaction
fee,
distribution
model
and,
of
course,
the
sukhoi
simulator,
which
is
that
I
talked
about
how
we
can
run
forward
in
time.
We're
planning
it
for
an
off-site
right
now.
We're
looking
at
February
I
may
move
that
to
March
after
the
beta
after
the
alpha
test
that
time
frame,
the
guys
need
every
moment
to
get
tent
done.
A
So
I
may
push
this
back
to
April,
actually
I'm
going
to
talk
to
them
Wednesday,
but
now
they
have
a
preview
to
that
weekly
workshops.
Every
Thursday
at
8
a.m.
Pacific
and
4
p.m.
Pacific
8:00
a.m.
for
is,
is
for
us
and
East
Coast
4
p.m.
is
for
Asia
pack.
You
know
Korea
Japan,
China,
folks,
folks,
that
are
in
the
UTC
plus
five
time.
A
Zones
such
as
India,
if
need
be,
I,
can
do
this
additional
session
that
later
at
night,
our
next
weekly
workshop
this
week
is
going
to
be
focused
on
weighted
keys,
are
baked
in
Multi
signature
functionality
and
thresholds,
how
thresholds
can
be
modified
in
contracts
and
how
Thresh
weighted
keys
can
be
modified
as
well
key
weights
associate
weights
and
how
you
can
add
and
subtract
signing
permission.
So
last
week
we
showed
account
delegation
base
the
granting
the
authority
of
a
tertiary
account
to
send
funds
from
a
primary
account
which
basically
enables
account
recovery.
A
As
long
as
you
don't
lose
the
keys
for
account
number
one.
You
can
assign
a
signing
rights
to
count
two
and
three
and
if
account
two
or
three
gets
lost,
it's
no
big
deal.
You
can
always
recover
using
key
one,
so
we're
actually
going
to
build
a
wallet.
A
multi
signature
wallet
that
prototypes
this
account
recovery.
Right
now,
we're
focused
on
the
ecosystem,
building
the
multi
token
vesting
right.
So
we
have
this
concept
of
stock
option
vesting.
A
You
can
easily
tokenize
your
stock
option
program
and
have
a
vesting
program
for
your
stock
options
on
the
cazuelas
blockchain
and
we're
going
to
prototype
those
contracts.
So
you
can
see
how
vesting
works
for
those
of
you
unfamiliar
any
token
grants
given
on
the
Castros
blockchain,
including
the
validator
tokens
for
genesis,
we'll
all
be
subject
to
a
lock-up,
and
they
will
vest
over
a
period
of
time
and
so
will
actually
be
dogfooding.
A
These
token,
vesting
example
is
because
we'll
be
using
them
in
our
own
smart
contracts
for
the
platform,
so
with
that
I'm
gonna
turn
it
over
to
Alex
who's.
Gonna
talk
about
economics.
If
there's
any
questions,
you
can
absolutely
add
the
questions
in
the
Q&A.
You
can
also
add
them
in
the
YouTube
Alex.
You
want
to
share
your
screen.
B
Certainly
in
a
second
actually
you
can
leave
this
up
for
a
couple
of
minutes,
because
there
is
actually
a
couple
of
things
to
talk
about.
So,
as
meta
mentioned,
you
know,
you're
working
on
you
know
fairly
sophisticated
simulator
for
the
entire
blockchain
and
additionally,
an
estimator
also
mentioned.
What
we
were
looking
to
find
out
is
whether
we
can
get
to
a
you
know:
desirable,
dynamic,
Nash
equilibrium
once
we
start
running
these
simulations,
so
the
economics
component
here
is
essentially
add-in
for
developing
formal
language
around
the
simulations
that
enables
us
to
formally
define
what
you
know.
B
What
is
a
strategy
for
a
validator
right,
because
once
we
have
that
formal
language,
we
can
actually
implement
the
tip
code
and,
have
you
know,
validators
act
as
rational
agents
vision
as
the
confines
with
a
simulator,
because
right
now,
of
course,
they
do
not
do
that
right
now,
they're
sensual
model
does
being
you
know,
dump
servers,
but
they
deal.
We
want
them
to
be
essentially
maximizing
some
kind
of
a
utility
function,
and
once
you
have
that
you
can
actually,
you
know
essentially
formally
talk
about
finding
dynamic
nasha
to
using
the
simulator.
B
So
that
is
economics
component
of
that
for
so
I'm,
currently
working
on
open
auctions
and
soon
we'll
be
working
on
design
of
price.
So
we
don't
really
have
a
model
for
comprehensive
model
for
price
and
right
now,
but
roughly
speaking,
we'll
be
looking
at,
you
know,
exists
in
economics,
research
and
you
know
price
and
kind
of
these
compound
goods
such
as
what
you
know
the
platform's
effectively
selling
here,
which
is
you
know,
computation,
storage
and
bandwidth
combined
and
finally,
now
I
can
actually
share
my
screen
and
well
I.
B
Guess,
what's
my
time
here,
let's
see
right
so
I've
talked
about
the
new
model
for
validator
entry
into
the
platform
before
in
very
general
terms,
and
since
then
I've
done
some
design
work
on
this.
So
the
purpose
of
these
open
auctions
is
it
you
know
so
the
present
blocky
model
relies
on.
You
know
everybody
validated
the
blocks,
consensus
history
so
because
of
this
there
is
a
trade-off
between
decentralization
and
performance.
B
So
now
so
we,
you
know
if
you
want
a
splat
from
designers
to
strike
as
a
correct
balance
here
you
know,
but
the
figures
is
the
previous
model,
which
was
a
bundle
model,
didn't
really
give
us
that
lever,
because
you
know
you
can
set,
you
can
set
the
minimum
bond
right
to
controls
and
abro
validators
entrant
with
three
imprecise
rating.
It's
a
very
awkward!
B
So
if
you
decided
to
go
for
soft
as
it
is
more
easily
controllable,
which
is
sort
of
like
a
basically
a
first
price
auction
for
slots
of,
if
there
is
a
fixed
number
right
is
fixed,
I
will
use
the
system
parameter,
which
is
what
enables
us
to
control
this.
The
centralization
performance
trade-off
and
the
you
know,
validators,
you
know,
make
sure
bids
line
up,
and
then
you
know
everybody.
You
know
it's
a
top
end
where
and
is
it
for
our
a
parameter
they
get
to
be?
B
Is
a
validator
set
for
the
next
era
and
note
that
while
it's
structured
like
a
first
price
auction,
what
you
bid
actually
becomes
your
ball.
So
you
know,
if
you
don't
later,
you
can
recover
it
right.
You
don't
actually
play
anything
to
anyone
so
overall,
this
there
are
few
other
aspects.
Here
is
oral
design,
goals
and
and
pray
you
know
looking
to
hit
here.
Are
you
know,
improve
the
platform?
Stupidity
eligibility
with
Shana?
You
know
this,
you
know
reducing
this
platform
parameter
ends.
B
B
This
has
the
role
of
fixing
a
known
problem
with
first
price
options.
So
first
price
options
have
been
first
tried.
You
know,
sort
of
in
the
internet,
applications
I,
think
I
believe
by
Yahoo
as
a
means
of
sell
in
search
hats,
and
it
was
very
quickly
discovered
that
first
price
options
result
in
extremely
unstable
price
and
writing.
It
jumps
around
all
the
time,
so
eventually
they
switched
to
second
price
auctions
and
stabilize
it.
B
The
problem
second
price
options
is
that
they're
harder
to
explain
right
first
price
auctions
are
very,
very
easy
to
explain
because
they're,
exactly
what
everybody
thinks
auctions
are
so
the
way
to
mitigate
this
pricing
volatility
is
to
make
everything
public
right,
I
mean
so
you
don't,
but
you
don't
have
to
guess
what
your
opponents
are
bidding.
You
see
everything
all
the
time
you
have
no
direct
predictions
of
who's.
B
A
So
this
is
thanks
for
sharing
this,
so
one
of
the
things
we
want
to
add
here
is
that
we
didn't
feel
comfortable
just
either
specifying
there.
There
are
a
couple
things
that
we
would
need
to
specify
right
is
that
what
is?
What
do
we
believe?
Is
the
minimum
bonding
amount,
the
max
bonding
amount,
and
we
just
didn't
feel
comfortable
that
that
was
something
that
we
could
specify
in
protocol.
We
didn't
feel
comfortable
that
a
governance
committee
could
specify
either
we
didn't
like
that.
A
A
The
demand
for
being
a
validator
would
be
on
our
blockchain.
The
other
thing
we
wanted
to
we
wanted
to
do
was
we
also
wanted
to,
because
we're
not
completely
certain
on
the
performance,
the
protocol
we
actually
wanted
to
see
if
there's
a
way
for
us
to
gradually
increase
the
decentralization
of
the
protocol
and
somehow
map
this
to
Moore's
law.
Thinking
that
as
bandwidth
increases,
so
will
the
impact
of
the
overhead
on
the
protocol
over
time
so
is
there?
A
Is
there
a
way
where
we
could
gradually
decentralize
and
increase
the
validator
set
pool
over
a
period
of
three
to
five
years
right?
So
maybe
you
know
we
start
off
at
Genesis
with
200
validator
slots
and
then
with
each
era.
If
an
era
is
a
day
we
would
increase,
you
know
one
validator
slot
a
day
or
if
an
air
is
a
week,
maybe
10
validator
slots
a
week
until
we're
we
cap
out
at
a
thousand
validators
right
after
three
years.
This
is
this
is
our
thinking
that
this
enables
us
to
gradually.
A
You
know,
extend
the
network
accessibility
to
the
network
over
time.
In
thinking
that
you
know,
bandwidth
will
increase
now.
Granted
bandwidth
isn't
going
to
increase
it.
That
Radle
I
think
it
will
increase
probably
a
little
bit
more
slowly
than
over
three
years,
but
this
this
was
our
thinking
around.
Why
we
chose
this
model
right
is
that
we
just
didn't
feel
comfortable
making
that
decision.
We
wanted
to
leave
it
up
to
the
market.
B
Right
so
I
mean
yes,
I
mean,
ideally,
you
know
we
leave
as
much
as
possible
to
the
market,
because
that
enables
us
essentially
to
discover
parameters
like
this
right,
I
mean
and
now
so
related
to
one
of
Vettes
points
right
regarding
not
wanting
to
have
the
governance
process
set.
You
know
critical
parameters
so
right
now,
for
this
you
know
number
of
slots
parameters.
There
are
a
few
ideas
on
how
to
be
protocol
itself.
B
The
simplest
one
is
to
tie
it
to
liveness
mechanically
in
some
sense
right
so
either
to
some
measure
of
you
know,
speed
of
finalization
or
to
some
kind
of
a
you
know,
aggregate
metric
horizon
from
you
know
validator
exponents,
but
something
along
those
lines
right.
So
essentially,
if
you
observe
over
times
that
the
platform
seems
to
be
operating
better
well,
you
know
you
can
bleed
off
some
of
this
performance
and
improve
security
by
increasing
the
number
of
slots-
and
you
know,
and
if
it
slows
down,
you
can
cut
the
number
of
slots
and
bias.
B
A
This
is
a
you
bring
up
an
excellent
point
like
this
was
one
of
the
points
that
Vlad
kept
kept
kind
of.
Hang
it
you
know
pampering
on
or
what
do
I
say
harping
on
with
us
is
that
he
really
wanted
us
to
think
about
the
user
experience
with
the
end-user
and
at
the
end
user
cares.
So
much
cares
the
most
about
is
time
to
finality
right,
and
so
that's
the
metric
that
you
kind
of
put
a
pin
in,
and
you
say
all
right.
We
want
to
provide
a
reasonable
time
to
finalization
plus
or
minus.
A
You
know
fifteen
percent
right
like
we're
not
going
to
swing
time
to
finalization
more
than
fifty
percent
15
percent,
and
what
are
the
one
of
the
levers
we
can
pull
on
that
right.
The
one
of
the
big
levers
is
the
validator
set
size
right.
A
smaller
validator
set
size
gets
you
very
fast
time
to
finalization,
but
less
security,
a
larger
validator
set
size,
increases
the
to
finalization
significantly,
but
gives
you
more
security.
A
So
if
you
find
that
the
network,
as
Alexander
has
mentioned,
that
the
network
is
processing
transactions
and
finalizing
them
very,
very
quickly,
very
efficiently,
you
can
afford
to
have
more
security
on
the
network
right.
The
key
is
that
isn't
figuring
out
what
this
time
to
latency
the
finalization
is
such
that
we
don't
wind
up
sacrificing
too
much
security
for
the
sake
of
finality.
So
these
are
things
that
we
were
thinking
a
lot
about.
It's
it's
complicated
but
very
interesting
and
intriguing
work
that
we're
doing.
B
B
You
know
kind
of
more
have
but
more
economic
and
spirit.
Let's
say
which
is
it?
You
know
conceivably,
one
could
also
leave.
You
know
this
aspect
of
the
platform
up
to
the
market
in
some
sense
right.
So,
for
example,
you
could
conceivably
let
people
buy
a
new
slot
right,
I
mean
so
effectively.
Auction
off
is
the
right
to
hold
an
additional
slot
and
you
know,
distributed
whatever
tokens
are
collected,
to
exist
in
participants
as
a
platform
to
compensate
them
for
loss
of
performance
right.
B
So
this
is
kind
of
a
broad
outline
of
you
know
what
we
are
currently
considering
as
one
of
interesting
difficulties
here.
Action
she's,
vices
design
dog
is
that
taking
a
little
longer
to
come
up
with
it
should
have.
Is
that
we
intend,
to
you
know,
support
extensive
delegation
of
tokens
by
users
for
staking
purposes.
B
So,
as
this
serves,
you
know
this
tries
to
achieve
two
goals.
The
first
one
is
to
enable
you
know
common
users
who
may
not
necessarily
make
Romania
transactions
to
protect
their
tokens
from
devaluation
because
of
seniority.
Right
I
mean.
If
we
want
people
to
whole
talk,
it's
right,
I
mean
we
don't
want
them
to
guess
you
web
buy
into
one
transactions
they
get
out.
We
want
them
to
be
on
the
platform.
You
know.
Of
course,
then
we
have
to
provide
them
the
tools
to
defend
themselves
against
you
know
valuation.
B
This
up
is
because
well
turns
out
that
the
delegation
introduces
few
wrinkles
into
the
process
of
designing
these
options,
because
you
know
we
must
treat
these
tokens
essentially
assumes
they
were
validator
tokens
right
and
then
you
have
to
think
about.
Well,
you
know
at
what
point
do
they?
You
know
count
first
date
how
they,
you
know,
count
towards
look
purse
that
the
US
contract
is
going
to
control
behalf
of
Aldi
for
a
stake
validator.
You
know:
how
do
they
unbond,
you
know,
can
say
and
bond
before
the
validation
but
well
I
mean
we
think.
B
Of
course
they
should
be
able
to
embody
first
of
all
they
can
pound.
So
there
are
a
few
aspects
to
these
open
options.
That
need
to
be
thought
through.
Is
that
you
know
when
we
first
came
up
with
this
idea?
You
know
it
was.
It
was
very
abstract,
and
now
we
are
working
all
these.
You
know
important
details.
B
A
Sounds
good
yeah,
the
the
interface
to
delegate
tokens
will
be
very,
very
simple
and
that's.
The
key
right
is
keeping
the
interface
super
simple
for
users
to
interact
with
thanks
for
that
I'm
gonna
do
a
quick
presentation
of
the
roadmap
and
where
folks
can
go
check
out
our
release.
Plans
I
feel
like
this
is
probably
something
is
super
important
to
kind
of
get
out
there
and
let
folks
take
check
it
out.
So
if
you
want
to
go
to
our
confluence
page
cast
for
Laughs
Atlassian
net,
we
have
spaces
slash,
release,
slash
overview
Ashok.
A
We
can
probably
put
this
on
the
update
on
the
current
status
on
github.
So
let's
just
get
that
out.
There
you'll
see
all
the
recent
releases
here,
but
you're
also
gonna
see
our
upcoming
releases
that
are
in
development,
no
12,
no
13
in
our
alpha
test
net.
So
no
12
is
what
is
presently
in
development
and
the
release
plan,
just
to
kind
of
lay
out
the
high-level
structure
on
the
left.
A
We'll
talk
about
the
simple
specification
of
what
we
are
building,
why
it's
important
who's
going
to
use
it
and
what
each
of
the
teams
are
working
on
and
their
associated
ticket.
My
goal
is
to
try
to
at
any
point
in
time.
Have
the
next
90
days
specified,
so
you
should
see
all
the
way
up
through
and
including
notes
for
Tina
and
chestnut,
so
that'll
get
through
March
31st.
A
Some
of
this
these
pieces,
I'm
gonna,
have
to
fill
in
so
work
in
progress,
but
dude
I
could
out
I
strongly
encourage
folks
to
check
it
out.
Note
13
again.
Here
we
talk
about
assembly
script,
which
is
planning
and
then
complete
the
functionality
required
for
alpha
test
net
and
prepare
for
our
test
at
launch
and
then,
of
course,
our
test
net
alpha
test
net
release
plan.
A
A
We
want
to
come
up
with
a
good
name
for
this,
but
we've
also
got
our
rewards
for
participation
on
what
the
games
look
like
what
we
want
to
learn
about
the
network
right,
so
this
is
and
I'm
also
very
much
open
to
hearing
comments
and
feedback.
You
can
always
send
me
feedback
on
discord.
Drop
me.
An
email
drop
us
an
email
at
hello
to
our
cast
for
labs
at
I/o.
A
If
you
find
something
on
here
that
is
worth
bringing
to
our
attention
and,
of
course
getting
involved
right,
we
would
love
to
have
people
get
involved
and
provide
us.
You
know
support
and
feedback
during
the
test
and
time
frame
and
just
to
give
a
little
bit
of
a
brief
overview
into
you
know
an
insight
into
my
process.
This
is
how
I
like
to
map
out
the
features,
the
roadmap
and
think
about.
A
What's
coming
up,
so
we've
got
our
alpha
test
net
here,
which
is
end
of
March
31st,
and
then
we've
got
node,
14,
15
and
16.
Then
we
expect
to
have
our
beta
test
net
after
the
node
16.
So
we'll
do
three.
Iterations
of
the
games
at
least,
and
then
completing
with
our
beta
testing
it
where
we're
completely
with
code
complete,
and
we
have
a
contract
registry
in
place
as
well,
so
node
14
we're
going
to
implement
the
validator
auction
adjustable
round
lathe.
This
is
what
we're
thinking
and
then
deploy.
A
So
this
is
a
little
bit
of
insight
into
how
we
think
about
community
and
ecosystem
and
what
the
different
pieces
are
that
flow
into
the
roadmap
are
so
a
little
insight
into
my
process
here
and
that's
it
for
me.
If
there's
questions,
people
can
raise
our
hands
or
shoot
me
a
note
later
on.
I'm
happy
to
answer
any
and
all
questions
you
can
catch
me
on
discord.
If
you
want
to
do
that
else,
want
to
talk
about.
Ashok
did
I
miss
anything.