►
From YouTube: Agoric Community Call #8
Description
First Wednesday of the month we will share Agoric announcements, answer live questions, highlight community projects, and introduce new tools to help you build your application on chain. Set your reminder here not to miss our Community Call.
A
Hello,
everyone
welcome
to
agoric's
eighth
community
call.
It's
may
5th
2021.,
I'm
rowan
grouse
product
manager
to
gorick
and
really
excited
to
have
you
all
here.
I've
got
a
lot
of
things
to
go
through
today,
so
let's
just
get
rolling
so
a
few
topics,
so
we're
going
to
talk
through
the
incentivized
test
net,
which
you
all
know
is
ongoing
right
now
and
it's
happening
in
several
phases,
we'll
talk
through
where
we're
at
what's
happened
over
the
past
month
and
then
the
next
phase,
that's
about
to
kick
off.
A
As
I
mentioned,
it's
happening
in
five
phases
and
right
now
we
are
about
to
start
staking
dynamics,
so
you
can
see
that
the
phase
three
actually
is
starting.
Basically,
today,
we've
had
two
phases
already.
The
onboarding
phase
really
was
mostly
about
having
all
of
our
validators
practice.
Getting
set
up
and
infrastructure
is
where
we
saw
the
first
initial
load.
We
saw
a
decentralized
chain
start
had
a
bunch
of
learnings
from
that
really
appreciated
everybody
in
the
community.
A
So,
let's
talk
about
sticking
dynamics
genesis,
so
validators
have
already
submitted
their
genesis
transactions
and
we
are
actually
in
the
process
of
generating
the
genesis
block
right
now,
so
I
actually
don't
have
discord
up,
but
that
should
be
coming
out
in
the
next
few
minutes
and
then
the
decentralized
chain
start
is
going
to
happen.
Thursday
may
6th,
which
is
tomorrow
almost
exactly
24
hours
from
now
at
9am,
so
that
got
moved
out
one
day
just
to
make
sure
that
everybody's
got
enough
time
to
get
rolling.
A
So
the
centralized
chain
start
last
time
was
pretty
fun.
So
it's
going
to
be
fun
again.
We'll
have
everyone
on
discord.
It's
a
party,
if
you're
a
validator,
making
sure
make
sure
that
your
node
is
ready
before
then
all
right.
So
let's
also
talk
about
the
last
phase,
so
we
had
a
huge
amount
of
participation
in
39
published
articles
over
90
of
the
network.
Tasks
were
completed
by
people.
A
The
challenge
tasks
are
really
additional,
either
dashboards
or
software
that
we're
looking
for
to
help
validators
help
other
users
work
with
the
chain,
and
so
when
people
take
their
time
to
submit
those,
that's
a
really
great
sign,
and
we
we
really
appreciate
it
and
been
excited
to
see
all
the
support
we've
gotten
beyond
that.
We've
been
really
really
excited
to
see
how
you've
all
supported
each
other.
So
it
you
know
in
the
discord.
People
are
asking
questions.
A
Other
validators
are
answering
that's
such
a
huge
help
for
the
chain
and
we've
really
seen
a
lot
of
good
camaraderie
there.
So
you
know
this
is
the
community
call
and
we
really
just
want
to
call
out
that
the
community
so
far
has
has
been
doing
such
a
great
job
during
this
test
net?
We
also
have
appreciated.
You
know
a
number
of
you
reached
out
to
us
on
ways
that
we
can
improve
our
documentation,
things
that
were
weren't
clear
and
please
keep
doing
that.
You
know,
I
think,
from
the
agoric
perspective.
A
A
Okay,
so
let's
talk
about
the
staking
dynamics,
phase
which
is
kicking
off
today
and
technically
the
chain
starters
tomorrow,
but
the
way
I
like
to
think
about
it.
We've
we
actually
have
a
whole
bunch
of
tech
that
is
coming
together
for
the
staking
dynamics
phase.
So
last
month
we
released
our
beta,
and
that
was
the
first
real
interaction
with
treasury,
vaults
and
the
amm
pools
for
trading.
A
You
know,
users
can
come
in
download
the
wallet
and
interact
with
a
live
hosted
chain,
hosted
application
to
actually
deal
with
the
economic
institutions
that
will
form
the
core
of
the
agoric
economy
and,
with
the
staking
dynamics,
phase
we're
actually
adding
the
the
next
piece
to
that.
So
the
the
amm,
for
example.
A
Now
when
you
trade
on
that
that
will
actually
generate
a
protocol
fee
and
that
protocol
fee
can
be
collected
by
agorik
and
distributed
to
stakers
and
validators,
as
as
part
of
their
role
in
securing
the
economy
and
similarly
with
the
vault.
So
as
a
the
vault
earns
interest
that
gets
paid
out
as
well,
so
the
piece
that
connects
the
economy
back
to
stakers
and
validators
and
really
creates
the
loop
that
makes
the
agora
chain
and
economy
work
is
completed
for
the
first
time
as
part
of
this
phase.
A
Beyond
that,
and
this
this
starts
to
get
a
little
bit
more
technical.
But
beyond
that,
we've
also
completed
a
really
core
piece
of
work
that
allows
the
cosmos
layer
to
talk
to
the
agorak
vm
layer
swing
set,
so
that
your
your
balance,
which
might
exist
on
the
cosmos
layer
for
build
now,
can
also
be
represented
in
javascript,
and
you
can
take
that
build
and
do
interesting
things
with
it
in
the
igori
economy.
A
So
being
able
to
move
back
and
forth
between
the
the
gore
vm
and
cosmos
is
a
critical
piece
of
infrastructure
that
has
has
come
together
for
this
phase.
So
you
know
it
it's
kind
of
it's
great
from
our
side
to
finally
see
all
this
stuff
actually
connecting,
and
we
hope
that
validators
who
are
in
this
phase
will
start
to
see
it
as
well
and
you'll,
see
you'll,
see
some
of
that
reflected
in
the
tasks
that
we'll
be
asking
you
to
do
is
actually
interacting
with
a
bunch
of
these
pieces.
A
A
So
the
one
piece
that
I
didn't
really
talk
about,
that
also
has
been
a
huge
effort
on
the
agoric
side
in
preparation
for
this
phase
is
the
transition
to
xs,
as
as
part
of
staking
dynamics,
so
I'm
going
to
bring
on
dean
tribble,
who
you
all
know
and
dan
connolly
who
most
of
you
and
discord,
know
but
probably
haven't
met
before
to
talk
about
what
that
means
for
the
agora
platform.
So
let's
bring
them
on.
B
Hello,
hello
and
hello,
everyone
out
there.
I
would
so.
I
actually
propose
that
we
talk
about
xs,
because
it's
such
an
important
piece
of
what
we're,
what
we're
sort
of
what
we're
building
in
terms
of
system
architecture,
and
it
affects
the
validators
right
now
and
we
really
haven't,
talked
very
much
about
it
at
all.
And
so
so
I'm
here
I
have
dan
connolly
here.
C
Yes,
there
was
one
or
two
other
blockchain
projects.
I
I
stuck.
My
toe
in
the
water
was
ethereum
and
I
did
a
little
stuff
on
on
our
chain,
which
is
another
one
that
uses
capabilities
anyway,
but
it
was
the
xs
engine
was
the
first
place
where
they
said.
Oh,
yes,
we
need
somebody
to
work
on
that,
and
I
said
oh
yes,
this
thing
is
great
fun.
I
had
already
bought
myself
one
and
taught
it
to
do
a
little,
a
little
secure,
javascript
stuff.
B
I'll
say
a
little
about
so
so
I
first
met
the
moddable
guys
at
atc39
at
a
javascript
standards
meeting,
and
so
this
is
one
of
their
computers
that
has
a
full
display
and
a
and
a
touch
screen
on
the
front
with
it,
whether
you
can
write
with
a
pen
and
play
games
and
stuff.
Like
that,
the
same
you
know,
and
it
is
a
it
is
a
standard.
You
know,
standards
compliant
javascript
engine
designed
to
run
on
chips
as
small
as
light
bulbs.
B
We
did
a
joint
presentation
with
mautable
and
metamask
last
year,
where
they
were,
they
were
demonstrating.
You
know,
programming
their
light
bulbs
in
in
javascript,
but
it
also
runs
in
washing
machines
and
dishwashers,
and
you
know,
I
think,
there's
some
medical
devices
starting
to
use
it.
So
it
is
so
modables
xs
is
a
javascript
engine
really
designed
for
small
memory,
footprint,
high
reliability
systems
and
that
sort
of
you
know
when
they
first
talked
about
that
at
the
javascript
standards
meeting.
We
got
very
excited
about
that.
B
Addressing
some
of
the
you
know,
we
knew
we
wanted
smart
contracts
in
javascript,
but
node
is
really
big
and
really
complicated
and
and
and
really
fast,
but
but
big
and
complicated
means
you
know,
buggy
and
and
and
and-
and
perhaps
you
know
dangerous
to
to
to
rely
on
there
being
no
exploits,
and
so
this
gave
us
a
another
avenue
to
to
much
higher
reliability
systems,
so
there
yeah.
So
I
have
one
of
the
same
things.
It's
funny
that
you
have
the
same
device.
B
So
after
that,
so
we
met,
we
met
them.
We
met
them
there
and
we
had
already
been
working
on.
This
was
in
2017,
maybe
maybe
it's
2018.,
but
we
had
already
been
working
on
the
secure
javascript,
the
the
the
sess
subset
for
being
able
to
do.
You
know
safe
extension
and
safe
smart
contracts
with
confined
javascript
programs
and
that
lined
up
well
with
what
embedded
systems
need
right.
Much
of
making
safe
javascript
is
locking
down
the
things
that
that
that
you
didn't
need
to
be
mutable
right.
B
You
know
I,
as
I
express
it,
you
know.
Javascript
starts
with
a
foundation
of
quicksand
where
any
anyone
can
change
array
iteration
to
steal
your
secrets
and
then
iterate,
the
array
or,
or
you
know,
change
number
reformat
to
print
it
out
on
my
printer
and
then
tell
your
format
right
and
the
lockdown
work
that
we
did,
that
we
have
in
sas
turns
that
sand.
That
turns
that
quicksand
into
concrete
and
they
in
embedded
systems.
You
really
want
concrete.
You
really
want
the
system
to
be
exactly
as
specified
work.
B
The
way
it's
going
to
work
and
be
able
to
write
your
your
your
device
controller,
your
you
know
your
dishwasher
controller
or
whatever.
It
is
in
a
system
that
that
has
high
reliability,
same
set
of
requirements
and
so
peter
hoddy
of
moddable
and
patrick
socal.
They
they
started
the
embedded
systems
standards
group
tc53,
which
is
javascript
for
embedded
systems,
and
you
know
it's
grown
since
then.
I
think
that
I
don't
remember
the
the
formal
title
of
it.
B
Maybe
someone
will
pipe
in
on
on
on
chat
but
but,
and
that
group
then
included
not
just
them,
but
other
people
doing
device
level
javascript
adopted
the
secure
javascript
are
our
lock
down
hardened
ses
as
the
standard
javascript
for
embedded
systems.
So
there
are
two
javascript
standards
group,
the
general
one,
for
you
know
the
language
across
browsers
and
node
and
and
and
endo
and
and
whatever
the
next
platform
is,
and
then
the
embedded
systems
group
and
the
embedded
system
group
just
said:
okay,
all
that
malleable
dangerous
stuff
yeah.
We
don't
need
that.
B
Right,
it
can't
be
very
malleable
if
it's
wrong.
Actually
they
did
amazing
work
to
make
it
so
that
even
the
stuff,
that's
in
rom
that
can't
be
rewritten,
it's
all
designed
so
that
it
can
be
overridden
in
ram.
So
the
the
one
percent
that
you
decide
to
mutate,
it
overrides
in
ram
and
all
the
rom
stuff
is,
is
you
know,
burned
in
and
can't
be
changed
and
all
that?
But
it's
nice
to
not
have
to
do
that
anyway,
so
yep
yep.
B
So
so
anyway,
we
we
saw
this,
and
so
we
wanted
to
bring
in
javascript.
You
know
I
I
sent
out
a
message
somewhere:
oh
in
our
engineering
news,
everyone
who,
who
watches
these
calls,
should
really
chat,
get
on
our
mailing
list
and
get
the
engineering
news.
But
you
know
node.js
is
wonderful.
It's
great!
B
In
a
bunch
of
different
vari
in
a
bunch
of
different
areas
and
it's
running
on
v8,
which
needs
to
be
not
just
fast
for
node
but
fast
for
browsers
and
stuff
like
that,
and
so
its
trade-offs
are
not
necessarily
around
high
reliability
right
and
xs.
Instead
has
these
trade-offs
around
small
memory,
footprint,
high
reliability
and
that
sort
of
thing,
and
so
that
was
attractive
to
us
and
then
you
know
we
met
the.
B
We
met
the
engineers
behind
it,
the
team
behind
it
and
and
and
hit
it
off
well
from
from
a
sort
of
philosophical
and
engineering
bent
and
and
the
idea
of
being
able
to
build
this
into
into
yet
another
environment
of
blockchain,
and
so
that
you
know
so.
We
have
since
been
having
this
background
effort
of
let's
make
sure
that
we're
building
everything
so
we'll
be
able
to
move
it
over
to
run
on
xs.
So
so,
when
did
that
happen?
When
did
that?
Finally,
work.
B
At
various
engineering
meetings,
I
would
end
up
saying
you
know
closer
now
than
ever
before,
which
is
a
phrase
I
got
for
either
eric
drexler
or
mark
stigler
or
something.
But
but
you
know
within
the
last
month,
suddenly
all
of
our
unit
tests
right
we
launched
shortly.
We
launched
the
contract
layer,
we'd
launched
swing
set
and
it
would
be
able
to
run
all
of
our
unit
tests
inside
of
xs,
with
no
with
no
errors
with
all
the
the
the
the
expected
behavior
and
that
sort
of
thing,
and
so
that
was
right.
C
C
C
We
might,
you
know,
put
more
than
one
in
one
in
a
unix
process
in
the
future,
but
right
now,
they're
exactly
unix
processes,
so
you
run
ps
and
you
can
see
all
the
vats,
and
so
it's
exactly
the
smart
contract,
deterministic
execution
stuff
that
gets
run
in
excess
and
it
gets
metered.
And
so
you
know
the
jit
is
really
nice.
C
B
Instead,
you
submit
your
javascript
program
to
chain
execution
and
then
it
would
rewrite
it
to
preserve
all
the
debugging
lines
and
all
that
sort
of
thing
but
insert
the
metering
calls
that
rewrite
meant
that
installing
a
contract
took
some
time
you
know
now.
Could
we
certainly
could
have
sped
that
up
a
lot
but
launching
it
onto
onto
the
the
accents
engine
means
we
don't
have
to
do
that
rewrite
because
we
don't
because
the
exception
x
engine
the
xs
engine
has.
We
need
to
find
another
name
has,
has
metering
built
in.
B
That
was
one
of
the
things
that
that
dan
worked
on
over
the
last
year
and
we
collaborated
with
the
model
folk
as
well,
where
they
did
a
bunch
of
the
core
implementation
to
integrate
the
things
we
need
for
our
usage
into
the
core
jaw
into
the
core
access
javascript
engine.
So
it's
available
not
just
us
but
to
everybody
else,
because
moddable
xs
is
an
open
source
engine
and
so
and
so
having
metering
built
in
means
that
we're
able
to
do
that.
You
know
it's.
It's
now.
B
B
B
C
B
Right
right
right
right:
yes,
yes,
not
that
bad,
so
so
there's
sort
of
a
couple
of
cool
things
here.
One
is
of
course,
we've
been
working
with
them:
they've
enhancing
the
debugging
support
as
we've
been
adding,
for
example,
standard
format
for
debugging
information
as
part
of
the
javascript
standards
group.
You
know
all
the
javascript
standards
work.
Of
course
the
xs
engine
follows
very
quickly
and
is
is
part
of
that
whole
process.
B
The
part
of
the
standards
group,
but
there
is
in
progress,
standard
ways
of
getting
stack,
information
on
error
reports
or
that
sort
of
thing,
and
so
audible's
added
that
stuff
and
that
provides
better
error
reporting.
The
error
reporting
that
we
now
get
out
of
contract
development
on
our
platform
is
is
really
nice
and
you
know
it's
it's
already
nice
and
what
people
might
not
realize
is
it's
amazingly
nice,
even
though
your
stack
is
actually
spanning.
B
You
know
the
ag
solo
on
my
machine
three
different,
separate
processes
on
running
on
chain
and
and
at
some
elements
in
the
browser,
and
you
can
end
up
seeing
a
full-on
call
graph
that
spans
multiple
machines
so
that
that
part
of
the
distributed
environment
of
of
the
agora
you
know,
vision
of
of
javascript
spanning
multiple
machines
is
starting,
is
really
showing
up
and
visible.
When
you
see
one
of
these
cross
chain,
remoted
stack
traces
and
so
the
xs
model
all
plays
well
with
that
right.
B
It
does
not
integrate
with
the
the
vs
code
debugger
at
this
point,
however,
but
this
is
where
some
of
the
crazy
stuff
that
we
do
not
yet
do
but
will-
or
I
don't
know
how
close
do
we
get
to
to
being
able
to
rerun
the
same
computation
under
node
and
under
xs?
What
is
that?
What's?
What
are
the
hooks
for
that
now
and
then,
where
are
we
going
with
that.
C
For
all
I
know
they
finished
that
last
night
I
know
they've
been
working
talking
about
it
in
the
last
three
days
or
something.
But
yes
this
idea
that
if,
if
things
don't
go
right
quite
right
on
the
on
the
blockchain-
and
you
want
to
be
able
to
use
your
nicer
developer
tools
to
to
take
a
look
and
replay
it
because
you
know
we
do
this
deterministic
execution,
because
we
record
every
message
that
comes
in,
and
so
you
just
replay
the
messages
and
you
should
see
the
same
execution.
B
Yep
one
of
the
one
of
you
know
I
know,
there's
there's
validator
challenges
for
better
explorers
and
better
and
and
better.
You
know,
analysis
tools,
one
of
the
things
that
that
I
want
I
want
to
see
and
that
we
that
we
certainly
plan
to
have
if
we
don't
already
have
it,
is
in
a
block
explorer
on
this
block,
click
and
re-run
all
the
contract
experts
right.
B
Yes
right
and
you
know
no
one's,
no
one's
gotten
there
yet,
but
all
the
hooks
are
there
to
be
able
to
do
that,
and
that's
certainly
something
that
I
expect
to
have
before
production
is
exactly
in
the
block
explorer.
You
know
the
the
merkle
tree
does
not
have
all
the
data.
That's
in
the
smart
contracts
so
run
that
block
you
know
start
a
checkpoint.
C
B
So,
okay
debugging
experience
right
now.
You
wouldn't
necessarily
want
to
do
your
contract
iterative
development
on
top
of
the
xs
engine,
but
in
executing
you
know,
javascript
standard
that
suits
exactly
the
same
or
you
know
modular
performance
issues
we'll
talk
about
a
minute.
It
actually
executes
exactly
the
same
as
if
it
was
running
on
node.
So
when
the
engine
starts,
when
the
the
the
the
the
agora
chain
starts,
when
the
swing
set
starts,
it's
got
a
flag
to
say:
do
I
launch
vats?
B
C
You
mentioned
determining
deterministic
execution.
We
were
debugging
something
the
other
day
and
and
running
it
for
half
an
hour
or
whatever,
and
we
had
running
zoe
contracts
and
all
this
kind
of
stuff
and
we
weren't
sure
if
it
was
doing
something
different
in
some
cases,
it
was
doing
exactly
the
same
thing
to
five
significant
digits
that
the
the
compute
meter
showed.
So
it's
like
blank.
You
know
this
thing's
yeah,
it's
working.
B
What
was
the
what
was
brian
warner?
Our
our
lead
engineer,
I
think
his
phrase
was
an
over-enthusiastic,
assert
right.
It
was
asserting
in
scenarios
where,
where
it
didn't
need
to-
and
you
know
I
don't
know
whether
they
did
this
time
but
being
able
to
fix
that
assert
and
then
not
start
over,
but
simply
re-run
that
vat
to
catch
up
and
replay
everything
up
to
the
point
where
the
assert
would
have
failed.
But
now
it's
running
just
slightly
different
code.
That
now
doesn't
fail
that
assert.
B
B
A
A
B
B
When
you
start
to
scale
right,
you
know
if
you're,
if
your
by
far
typical
cases,
arrays
with
10
elements,
then
you
don't
do
the
optimization.
You
would
need
to
do
if
you
might
be
dealing
with
a
raise
of
100
000
elements,
and
so
there
are
places
where
that
optimization
is
not
the
right
thing
for
the
chain
and
we've
already
and,
and
so
the
last
week
has
been
spent,
discovering
the
low-hanging
fruit
of
those
optimizations
and
changing
them,
and
many
of
those
are
just
tuning
parameters.
B
You
know
there
was
one
or
two
bugs
that
are
irrelevant
to
the
embedded
systems
case,
but
are
relevant
to
us
not
in
terms
of
memory
safety,
but
just
in
terms
of
allocation
efficiency,
and
then
there
are
going
to
be
ones
that
we
have
not
yet
run
against.
That
we
know
are
not
that
we
know
won't
scale
enough,
for
example,
to
survive
our
next
test
net
phase,
which
is
and
we'll
be
working
on
those
and
and
addressing
those
between
now
and
stress
test.
B
So
that's
where
he's
saying
the
memory
may
climb
or
the
block
performance
may
slow,
because
there's
something
that's
just
that
just
got
an
n
squared
performance
to
it
that
will
go
away.
The
other
thing
is
that,
as
as
part
of
a
desire
to
prioritize
getting
this
in,
there
are
elements
of
garbage
collection
that
we
turned
off
so
things
that
that
we
already
know
how
to
clean
up,
but
we
aren't
currently
because
some
other
pieces
relying
on
you
know
weak
pointers
to
it
or
that
heck
it
is.
We've
pinned
those
in
place.
B
It's
what
brian
calls
our
safety
pins.
You
know,
so
we
so
we
would
rather
grow
memory
a
little
bit
right
now
in
order
to
get
the
rest
of
the.
The
testing
done
then
have
a
dangling
pointer
and
so
that
stuff,
too,
will
be
cleaned
up
over
or
you
know,
addressed
over
the
next
couple
of
months,
but
that
will
cause
memory
footprints
to
grow.
So
so
we
want
the
validators
to
have
experience
with
lots
of
lots
of
processes
being
spawned.
B
We
want
them
to
have
experience
with
tracking
all
of
these
different
processes
that
have
different
small
memory
footprints.
You
know
they
have
different.
You
know
each
one
of
these
separate
engines
has
a
different
checkpointing
file,
so
we
didn't
talk
about
checkpoint,
but
these
engines
are
such
that
the
entire
javascript
engine
for
a
vat
can
separately
checkpoint.
So
if
the
thing
terminates
it
can,
you
know,
can
be
swapped
out
of
memory
brought
into
memory
when
we
restart
we
can
restart
from
checkpoint
instead
of
having
to
play
everything
from
the
beginning.
B
Since
we
know
the
checkpoint
is
a
deterministic
result
of
replay,
that's
just
an
optimization
and
it
still
keeps
that
nice
determinist
execution
semantics,
and
so
all
of
those
elements
are
new
with
this,
and
so
any
one
of
them
could
be.
You
know
it's
it's
it's
novel
territory
here,
it's
really
awesome
stuff,
that's
coming
together
here
and
you
know,
and
and
and
the
validators
are
going
to
be,
our
are
our
you
know,
they're,
not
the
first
line
of
events.
We
definitely
have
done
plenty
of
testing
ourselves,
but
certainly
the
second.
A
A
Roland
all
right
so,
as
you
guys,
can
tell
there's
sort
of
a
lot
that
has
gone
into
this
integration
and
and
as
I
mentioned,
you
know,
this
is
something
that
we're
really
excited
about
in
terms
of
effects.
You
know,
as
dean
and
dan
both
mentioned
memory,
footprints
might
grow.
We
might
might
see
some
performance
stuff
during
this
phase.
The
actual
load
testing
that
we're
doing
is
relatively
minimal,
but
for
stress
tests
it
will
not
be
so.
There
will
be
processes
running
in
part
to
generate
fees.
A
So
we
will,
we
will
see
things
grow
over
the
course
of
the
phase.
We
think
it
should
be
fine,
but
you
know,
as
dean
said,
this
is
all
new,
so
we're
really
excited
and
we
appreciate
all
the
validators
coming
and
helping
us
test
this
as
we
launch
so
with
that
I'm
gonna
transition
from
the
incentivized
test
net
to
talk
a
little
bit
about
the
upcoming
developer
program
and
developer
beta
bounties
that
that
we're
looking
to
put
together
here.
A
So
this
is
a
program
that
we
we've
been
talking
about
internally
and
and
working
on
for
quite
a
while,
and
so
this
is
the
first
time
that
we're
really
discussing
it
externally,
but
it
this
has
been
a
topic
of
long
conversation
here
as
we
approach
mainnet.
We
know
that
there's
a
whole
bunch
of
stuff
that
you
know
we
don't
either
have
time
to
build
internally
or
think
should
be
built
by
third
parties,
but
also
in
general,
want
to
make
sure
that
we
have
you
know.
A
Parts
of
the
community
are
extremely
talented
developers.
We've
already
seen
it
with
a
lot
of
the
the
challenge
tasks
that
got
submitted
and
people
talking
to
us
in
discord,
so
we're
really
excited
to
put
together
a
program
that
will
have
specific
bounties
structured
for
developers
who
are
interested
in
working
on
them,
and
so
the
way
to
think
about
this
is
we've
got
three
different
categories
of
bounties
that
we're
thinking
about
right.
A
Now
one
is
tools
and
infrastructure,
so
things
like,
for
example,
dean
mentioned
in
passing,
an
explorer
for
things
that
are
happening
in
our
swing
set
layer,
and
you
know
that
gets
more
interesting
with
excess
running
core
default
components.
So
these
might
be
things
that
are
higher
up
in
the
stack
more
you
think
of
it
more
like
application
level
stuff
that
is
critical
for
a
functioning
economy.
A
So,
for
example,
we
might
need
a
loan
protocol,
we
might
need
a
synthetic
asset
protocol
and
we
have
some
examples
on
the
next
slide
and
then
also
front-end
design.
So
the
a
lot
of
the
the
front-end
work
that
we've
done
has
been
sort
of
in
preparation
for
phases
or
releases,
but
has
not
been
the
sort
of
thing
that
we,
you
know:
we'd
love
to
get
some
specific,
front-end
talent,
working
on
our
treasury
or
working
on
our
wallet
or
other
user-facing
applications.
A
So
if
you
have
talent
or
interest
in
any
of
these
areas,
you
know
we'd
love
to
hear
from
you
and
there
will
be
a
survey.
That's
coming
out.
So
I'll
talk
about
that
in
a
minute
and
yeah
just
to
just
to
hit
hit
the
example
boundies-
and
I
think
I
just
talked
through
a
few
of
them,
but
re-implementing
our
gorick
wallet
front
end
and
react
right
now.
It's
done
in
svelt.
We
have
react
components
that
we've
used
for
the
treasury
dap,
but
being
able
to
put
a
skin
on
the
wallet.
A
A
So
the
the
way
to
get
started
or
the
way
to
prepare
is
get
to
know
the
tools,
so
starting
with
the
beta
site
is,
is
a
good
way
to
do
that
had
to
head
to
beta
use
the
treasury
application
as
a
user,
but
then
also
dig
into
the
code
and
start
digging
into
our
documentation.
Come
talk
to
us
in
discord
and
then
the
developer
survey
is
going
to
get
sent
out,
I
think
via
email
via
discord
via
telegram
and
and
what
we're
really
looking
for
there.
A
You
know,
I
know
a
number
of
you
have
already
joined
our
newsletter
list
and
things
like
that.
What
we're
looking
for
in
the
developer
surveys
to
understand
you
know
who
is
interested
in
spending
how
much
time
doing
what
kind
of
thing
right.
So
we
have
three
different.
I
mentioned
three
different
categories,
but
then
we
also
have
different
levels
of
effort
that
we
might
need
for
for
bounties.
Some
of
them
might
be
a
couple
days.
A
As
a
reminder,
the
beta
is
still
live
so
head
over
to
beta.gorick.com
you
can
there
you'll
be
linked
to
instructions
to
get
your
wallet
which
you
can
load
from
docker
and
then
you'll
be
able
to
interact
with
the
treasury
application.
If
you
haven't
done
that
yet
you
should.
You
should
do
that
and
if
you
are
a
validator
in
the
incentivized
test
net,
you
will
need
for
at
least
one
of
our
tasks.
A
You
will
need
to
interact
with
the
treasury
app,
so
getting
started
now
would
help
as
a
reminder
the
gravity
decks
competition
launched.
I
believe
two
days
ago
now
and
run
is
in
there
as
the
agoric,
the
agoric
stable
currency.
So
if
you
are
looking
to
trade
in
the
gravity
decks,
the
only
currency
peg
to
a
dollar
is
run,
so
you
know
just
want
to
plug
it.
We've
we've
several
of
us
have
joined
the
competition
and
would
love
to
see
more
of
the
community.
Do
that
as
well.
A
A
Finally,
so
what's
coming
up
next,
so
we
have
a
pillar
series
talk
with
dean
on
may
19th.
So
look
forward
to
that
and
likely
more
announcements
coming
over
the
next
several
weeks
as
well,
so
stay
tuned
on
discord,
stay
tuned
in
telegram
and
yeah.
As
always,
we
really
appreciate
everyone
in
the
community.
A
You
guys
have
been
it's
been
a
growing
community
and
you
guys
have
been
excellent
in
just
helping
each
other,
helping
us
and
being
positive
so-
and
I
just
saw
dean's
comment
in
youtube-
I
am
absolutely
a
run
whale
I'm,
which
is
a
very
conservative
thing
to
be,
but
I
guess
I
have
a
lot
of
run
in
the
gravity.
Decks
all
right.
Thanks
very.