►
From YouTube: NEAR Certified Demo | Episode 4.1 -- Bankable
Description
This demonstration was presented by the author(s) after just 1 week of working with the NEAR platform as part of the NEAR Certified Developer program.
You can find the source code to this demo here:
https://github.com/Learn-NEAR/NCD-04--bankable
---
Follow the latest from NEAR Protocol on:
Website: https://near.org/
Discord: https://near.chat/
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
#Blockchain #FutureIsNEAR #NEAR #nearprotocol
A
A
screen
here
near
bankable
is
up
next
and
on
deck.
Is
popular
team.
C
B
All
right
cool
just
play
that.
A
C
All
right
awesome,
awesome
right!
Oh
it's!
Okay!
Thank
you
very
much,
everybody
for
the
time
we're
near
bankable,
the
blockchain
bankers,
and
basically
our
project
is
looking
at
sort
of
like
how
we
can
create
a
banking
service,
so
decentralized
banking
service
which
sits
on
the
near
blockchain
and
basically
allows
dapps
to
basically
to
have
their
own
sort
of
like
banking
service,
which
means
that
you
know
you
don't
have
to
keep
sending
your
money
to
your
wallet.
C
You
can
actually,
you
know,
keep
it
on
on
chain,
but
in
a
safe
place,
and
you
can,
you
know,
deploy
somebody
like
a
finance
manager
to
keep
an
eye
over
it
to
approve
refunds,
and
things
like
that.
So
how
our
that
works
is
that
it
allows
developers
to
basically
palm
off
all
of
the
banking
features
of
their
dap
to
a
secure
location.
C
So
the
adapt
contracts
don't
have
to
hold
that
much
money,
and
it
also
allows
them
to
issue
refunds
in
a
nice
trackable
way,
so
that
allows
them
to
keep
their
that
code
purely
focused
on.
You
know
the
business
that
they
actually
have
to
do.
Whilst
the
new
bankable
contract,
you
know,
manages
all
of
the
safe
keeping
around,
you
know
the
custody
of
your
money,
how
your
refunds
behave
all
of
that
just
sort
of
like
paused
away.
It
also
allows
for
withdrawals
to
happen
now
in
our
current
implementation.
It's
very
simple!
C
C
And
basically,
they've
got
the
ability
to
sort
of
like
approve
and
decline
requests.
You
want
to
take
us
to
the
next
slide.
C
So
this
is
an
example.
Well,
this
is
a
diagram
represents
the
basic
architecture,
so
we
have
on
the
left
hand,
side.
We
have
the
dap
and
the
adapt
user
right,
they're
going
to
basically
deposit
funds
right
into
their
bank
contract.
Those
funds
will
be
held
in
there
until
they
either
withdrawn
or
funded
right.
C
If
something
goes
wrong
in
the
front
end,
and
basically
you
know
the
user's
requesting
a
refund,
they
make
a
refund
request
to
the
bank
contract
and
then
that
gets
put
into
queue
and
then
your
that
finance
officer,
they
will
simply
you
know,
go
and
see
what
list
of
kind
of
refund
requests
do
we
have,
and
then
you
know,
they'll
approve
the
ones
whereby
you
know
they've
looked
at
the
reason
code
and
what's
been
described
and
they're
happy
with
it
and
declined
the
ones
which
they're
not
and
at
the
end
of
the
day
or
whatever
the
period
is,
you
know
they
can
withdraw.
C
You
know
the
funds
from
the
contract
and
you
know,
keep
your
business
going
so
that,
in
a
nutshell,
is
what
we
set
out
to
achieve,
because
we
looked
at
it
and
we
said
that
you
know
this
is
going
to
help
us
really
understand
how
the
neo
blockchain
works
and
how
it's
different
from
other
blockchain
systems
and
how
it
you
know,
sort
of
like
helps
us
to
actually
move
that
needle
forward.
In
terms
of
understanding.
C
You
know
the
ins
and
the
outs
and
the
intricacies
around
near
that
operation
I'll
now
hand
over
to
my
colleague
sam
who
will
now
take
you
through
the
code
demo.
B
All
right,
so
I'm
gonna
quickly
just
go
over
the
code
demo
and
we
can
deploy
as
well
so.
B
A
A
B
Thanks
all
right,
so
we
decided
to
write
an
assembly
script.
That
is
the
language
that
all
of
us
were
the
most
comfortable
with
and
so
yeah
a
project
is
set
up
with
some
basic
boilerplate
assembly
script
and
we
have
written
basically
mainly
in
two
files,
there's
types.ts,
which
contains
all
the
types
that
are
relevant
for
our
app.
B
This
is
mostly
just
type
aliases,
however,
the
deposits
withdrawals
and
refunds
are
handled
via
classes,
which
are
then
passed
as
arguments,
which
leads
to
a
little
bit
cleaner
code
and
then,
finally,
we
have
the
index.ts
which
actually
handles
the
contract
itself.
So
inside
of
the
index
ts,
we
have
a
near
bankable
contract,
which
is
a
class
that
holds
all
the
information
that
is
necessary
for
the
contract
to
run.
B
B
Depositing
negative
funds
into
the
contract,
for
example,
or
nothing
at
all,
and
by
withdrawing.
We
also
have
to
all
check
whether
the
user
is
authorized
to
do
that
whatsoever
currently
for
testing
purposes
and
for
making
sure
that
the
contract
works
within
the
testing
framework
that
we
were
able
to
get
run
up
and
running
in
this.
In
this
short
time
frame,
there
are
some
functionalities
which
are
either
disabled
or
slightly
different,
for
example,
in
the
deposit
funds
function.
B
B
We
can
actually
check
these
and
cross-reference
them
with
the
context,
so
the
attach
deposit
and
the
sender
make
sure
that
those
are
equal
and
prevent
any
sort
of
tampering
with
data
that
way.
This
is
currently
disabled,
though,
for
simply
for
testing
purposes
and
yeah.
B
The
refunds
are
once
again
handled
similarly
to
the
depositing
of
funds.
So,
first
as
tower
already
explained,
refunds
are
basically
sent
over
from
the
from
the
dab
where
they
are
then.
First
is
obviously
checked
that
the
refund
is
for
an
existing
transaction
and
if
it
is,
then
that's
simply
added
to
a
queue
and
then
a
finance
officer
will
go
through
and
approve
the
refunds
manually
by
their
id,
and
obviously
everything
has
to
be
checked
to
make
sure
that
the
refunds
can
only
be
approved
or
declined
by
the
owner.
B
And
if,
if
it's
approved,
then
funds
will
be
sent
directly
to
actually
the
the
depositor
of
the
original
deposit,
which
is
the
contact
center.
Who
initially
bought
something.
So
the
customer,
the
app
user.
And
this
basically
is
you
know
very
efficient
that
we
can
just
send
it
right
over
to
the
user
without
any
middleware.
B
Yeah
seven.
Similarly,
when
it
is
declined,
we
just
simply
remove
it
from
the
from
the
from
the
key.
We
I
just
noticed
we
we
have
a
typo
here,
but
that
doesn't
matter
so
that
is
essentially
everything
to
that.
Actually,
let
me
walk
you
through
the
tests.
Real
quick,
I'm
gonna
run
those
but
look
at
them,
so
the
tests
essentially
just
check
that
everything
works
fine
with
the
dam.
B
These
are
some
basic
unit
tests
which
go
over
being
able
to
deposit
funds
and
yeah
other
functionality
could
also
be
checked.
However,
it
requires
disabling
some
functionality
for
unit
tests
specifically,
and
so
within.
Like
this
limited
framework,
we
really
didn't
have
too
much
time
to
to
go
through
that
and
make
all
those
tests
work
properly
as
they're
supposed
to.
B
Yep
there
we
go
tests
passed.
If
anything
were
to
fail,
it
would
give
us
a
nice
descriptive
message
of
what
exactly
failed.
I
also
have
prepared
a
look
at
the
documentation
which
is
available
under
readme
there's
a
guide
on
how
to
deploy
which
we
can
go
through.
I
should
probably
zoom
in
on
this
a
little
bit
this
guide
on
how
to
deploy
as
well
as
deploying
windows,
and
we
also
have
just
a
very
basic
overview
of
the
contract
interface
and
how
you
can
interact
with
the
contract.
B
So
that
would
be
everything
from
us
unless
you
want
to
see
this
deployment
went
through.
A
Do
you
have
the
contract
deployed
already?
Can
you
drive
it
to
see
what
it
looks
like
you
have
a
minute
left
we're
at
nine
minutes
right
now,
yeah.
B
I'll
just
have
you
trust
me
that
this
this
dev
thing
is
actually
working,
because
I
cleared
my
terminal
screen.
However
yeah
we
can,
for
example,
call
the
get
balance
on
the
on
the
contract,
which
is
deployed
at
this
address
and
that
will
currently
return
zero,
since
there
is
nothing
deposited
in
the
contract.
B
So
if
we
get
this
running.
B
B
Explorer
called
get
balance
in
this
contract
and
we
could
do
other
functions
as
well.
However,
since
we
only
have
a
minute
left,
it'll
be
a
little
time
consuming,
because
the
contracts
take
objects,
as
parameters
and
building
those
in
json
in
the
terminal
takes
a
little
while.