►
From YouTube: Swapr Weekly [2023-02-06]
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
welcome
to
swapper
weekly
today
we
have
the
agenda
here
posted
in
the
chats,
so
yeah
I
can
start
with
the
beta
19..
A
B
Yeah,
like
it's
all
on
for
review
now,
so
we
are
adding
new
events
for
for
people
that
click
in
Pro
chart
mode
or
off
chat
mode,
and
also
every
15
seconds.
We
launch
an
event
counting
how
many
people
are
sync
with
the
window.
Open
are
seeing
the
the
problem
of
and
yeah.
If
you
you
have
any
idea
to
how
to
have
patterns
better
events
or
if
you
find
it
confusing
for
the
naming
yeah.
B
Just
just
like
me,
you
know
material
the
link
you
can
see
here
in
the
events
section.
There
are
a
few
events,
if
you
don't
understand
them,
it's
better
to
to
have
like
the
last
30
days
selected
to
see
different
different
events
like
the
promote
click,
sharp
Pro
or
a
volume
for
promote,
and
also
the
15
seconds
on
promo,
yeah
and
I.
Think
it's
basically
that
it's
still
in
testing
but
yeah.
A
Cool
cool
yeah,
so
we
are
we're
waiting
on
this
to
complete
0x
trade
and
one
inch
was
integrated
to
the
develop,
and
that
would
be
nice
if
we
could
make
a
release
this
week
for
beta
19.
A
I'm
thinking,
maybe
the
swap
box
2.0-
might
be
complete
by
this
in
the
next
three
to
four
weeks,
so
probably
first
cut
version
of
the
swapbox
2.0
or
some
of
the
bridge,
aggregators
like
Levi
or
across,
might
be
good
to
good
to
add
and
then
a
few
few
more
networks.
Once
we
have
added
one
inch
and
zero
X,
maybe
we
could
also
open
it
up
for
a
few
other
networks.
I
think
yeah,
I
think
I
think
that
might
be
a
good
addition
for
beta20.
A
Cool
the
next
one,
I
just
thought
that
I
will
bring
this
up
so
velodrome
I
think
they've
brought
a
new
ads
like
their
V2,
where
they're
bringing
adding
additional
features.
A
A
A
And
also
carbon
carbon
is
I,
think
Banker's
next
version
of
amm,
where
they
mentioned
something
like
using
limit
orders
for
for
for
swapping
and
I
think
that
might
also
be
something
that
is
good
for
us
to
to
look
into
I.
Don't
have
a
URL
right
now,
but
yeah
I
will
probably
share
it
in
the
chats
when
I
find
one
yeah
and
then
I
and
then
I
was
thinking
that
maybe
if
we
proceed
working
on
liquidity.8,
it
might
be
good
to
just
take
some
inspiration
from
them.
A
Cool
moving
on
to
the
next
one,
I
leave
it
to
Nelson,
give
a
small
Orion
there.
We
are
sure.
C
C
C
C
Currently,
the
the
implementation
we
had
was
like
integrated
with
any
unib2
Fork
and
what
I'm
working
on
is
integrating
with
with
unib3
as
well,
so
it
can
work
with
both
on
the
design
pattern
here
was
having
a
common
interface
for
liquidity,
pools
where
the
functions
to
add
liquidity,
remove
liquidity
and
swap
tokens,
and
then
we
have
two
more
contracts:
implementations
that
like
implement
this,
this
interface,
one
for
unib2
and
the
other
one
for
unib3.
C
The
scope
of
the
interface
was
limited,
so
it
only
worked
with
uni
swap
both
with
2
and
B3,
so
it
could
potentially
be
extended
later
in
the
future.
For
all
the
liquidity
boost,
but
for
now
to
to
limit
resources,
it
will
only
be
for
those
two
and
how
it
works
is
there
are
some
like
hard
like
hot
cold
settings,
you
need
for
adding
liquidity
the
tokens,
the
minimum
amounts
you
will
get
to
manage
slippage
and
a
few
others,
and
then
the
the
ones
that
will
be
implementation.
C
Specific,
are
going
to
be
passed
like
in
codes
into
bytes.
That
way
like,
for
example,
on
unit
with
three,
you
need
to
send
the
liquidity
number
and
the
mean
and
maximum
rates
you
don't
really
send
mean
and
maximum
price
range
it's
it
sends
you
another
way,
and
then
it
does
some
calculations.
But
essentially
you
will
need
to
provide
the
range
and
that's
not
pressing
on
you-
need
me
too.
C
So
in
order
to
have
a
common
interface
that
can
work
for
both
those
that
data
is
encoded
into
into
bytes
and
like
the
universe,
implementation
will
just
ignore
those
on
the
universe,
3
implementation,
we'll
just
pass
them
and
use
them,
and
then
obviously,
on
the
front
end
we
will
have
like.
If
you
are
using
a
unity
pool,
it
will
send
the
proper
data
and,
if
you're,
using
B3
pool,
we
will
send
more
data
and
then
another
issue
I
found
while
I
was
doing
the
research
on
this
implementation
is
obviously
you.
C
If
you
didn't
know,
unib3
doesn't
use
LP
tokens
like
you,
don't
get
LP
tokens,
but
you
get
an
nft
which
is
associated
in
the
unib3.
Storage
of
the
of
the
contractor
is
a
mapping
that,
with
the
token
ID
has
like
all
the
data
for
the
position,
so
that
also
changes
the
the
infrastructure
of
this
design,
because
the
interface
will
also
take
care
of
the
approval
and
transfer
of
those
tokens.
C
That
way,
the
sapping
contract
can
just
call
this
common
interface
approve
and
transfer,
and
if
it's
univ2
it
will
approve
or
transfer
LP
tokens,
and
if
it's
univ3
it
will
transfer
the
the
ERT
721.
There
are
some.
There
were
also
some
issues
because
on
on
the
univ3,
when
you
are
like
mint
liquidity,
you
actually,
the
the
core
of
unity,
calls
a
function
on
the
contract,
that's
doing
the
minting
and
it
calls
a
function
when
it
receives
the
this
nft
and
that
has
to
be
implemented
in
the
subcontract.
C
But
it
doesn't
really
affect
any
other
implementation.
So
it's
just
a
code
that
will
be
used
by
unity,
but
and
it's
not
part
of
the
interface,
but
it
doesn't
really
affect
the
rest
so
that
that
was
one
of
the
issues,
but
that
that's
essentially
the
the
the
design
like.
We
have
one
interface,
two
implementations,
so
three
contracts
deployed
in
total
one
for
the
sapping
that
we'll
be
using
will
be
calling
this
interface
and
we'll
have
the
the
addresses
of
the
other
two
and
then
like.
C
When
you
add
a
new
decks
to
the
sapping
contracts,
you
will
specify
if
it's
going
to
be
unib2
or
any
other
fog
and
or
univ3
or
any
other
folk
of
universe
3
when
we
have
those
and
it
will
use
those
as
as
it
needs,
that's
the
the
main
design
and
and
the
issue
saying
I.
I
found
a
on
the
way
currently
I'm
finishing
the
removal
of
the
liquidity
and
I'm
like
halfway
done
with
the
with
the
swaps
on
the
b3w2
is
just
done
already.
C
Yeah,
that's
pretty
much
it
on
the
next
steps
would
be
like
think
about
how
the
front
end
will
be
not
sure
Binky.
We
don't
have
anything
for
the
unib2
front
right.
There
is
nothing
yet.
C
Yeah
hasn't
been
test
or
anything:
okay,
no,
no,
okay!
Well,
there
is
something
the
the
unib2
like
part
of
the
front
that
should
be
just
quite
stressful.
You
just
input
the
token
you
need
the
pool
you
want
to
open
to
and
you
just
go
for
it
on
the
universe.
3.
There
is
some
extra
data
you
will
need
to
input
and
some
calculations.
C
The
front
end
will
have
to
do,
but
I
can
provide
like
the
the
formulas
for
those,
but
we
can
still
like
the
the
design
or
a
similar
one
from
the
current
uni
B3.
Swap
because,
like
this
data
is
the
same,
the
only
difference
is.
We
will
only
provide
one
token,
but
essentially
you
need
like,
on
the
univ3
front
end.
So
if
you've
seen
it,
but
there
is
like
a
slider
when
you
can
increase
or
decrease
the
range
of
the
price.
C
So,
like
the
front,
end
gets
the
current
price
and
does
like
plus
five
percent
means
five
percent.
Something
like
that
and
you
can
just
move
around
and
and
like
ape
into
the
range
you
want.
That's
the
only
difference.
I
see
like
front
and
wise,
at
least
on
the
visual
side,
on
the
on
the
intern,
as
there
are
some
other
changes,
but
for
the
front
guys
shouldn't
be
too
hard
and
I
will
provide
all
the
math
and
that's
required
any
questions.
C
C
In
the
next
few
days,
I
will
finish
the
this
implementation.
Do
some
testing
I
still
have
to
write
like
all
the
unit
tests
as
well,
but
I
will
I
would
like
to
like
first
actually
deploy
and
untested.
C
It
works
all
the
way
and
after
that's
done,
I
would
take
like
a
day
or
two
to
do
a
more
in-depth,
like
Security
review,
make
sure
we
don't
have
any
holds
at
least
once
I
can
detect
and
after
that,
I
should
be
ready
to
to
to
start
planning
for
for
now
that,
so
it
will
be
three
contracts
that
we
will
need
out
on.
B
A
All
right
any
questions
so
far,
other
zapper.
A
Nope
cool
then
we'll
move
on
to
the
to
the
next
one.
Adam.
D
D
Let's
see
what
was
the
number
I
even
forgot:
okay,
so
erc's
ERC
1271,
and
this
is
basically
a
standard
that
car
also
uses
to
basically
verify
if
the
order
is
meeting
certain
conditions
on
a
contract
itself
and
then,
if
it's
valid,
then
it
will
go
ahead,
go
ahead
and
add
it
to
the
resolver
Network,
so
it
can
be
felt.
But
that's
the
only
thing
we're
currently
working
on
and
also
like,
maybe
like
design
wise
I,
had
a
call
with
that.
D
We
had
a
review
of
the
entire
application
where
I
think
we're
gonna.
Keep
it
simple.
Make
a
few
adjustments
then
see
how
we
can
launch
the
Alpha
version
of
this
or
the
MVP
in
the
next
few
weeks.
A
Cool
yeah:
that's
that's
how
I
actually
had
for
today,
but
anybody
has
any
questions
or
topics
that
want
to
bring
up
and
discuss.