over budget
Offchain Typescript library
Current Project Status
Unfunded
Amount
Received
$0
Amount
Requested
$65,000
Percentage
Received
0.00%
Solution

A library based on Typescript can both ensure web and mobile (React-native) easy integration and built-in documentation while coding

Problem

existing solutions for smart contract integration via browser (or mobile) are often hard to integrate and poorly documented

Addresses Challenge
Feasibility
Auditability

Team

1 member

Offchain Typescript library

Typescript is with every probability the go-to language when choosing to develop a large web application

frameworks such as React Vue and Svelte support it and Angular even makes it a must.

Adding an easy way to build transactions using Typescript will make the smart contract developers working experience as sweet as writing declarative code while having all the control of the imperative one

possible features are:

- automatically generated Metadata given a (JSON) serializable object

- SmartContract endpoints translated to simple transactions built in the browser (reducing or even removing a centralized server load)

- extremely easy blockchain queries by using the browser fetch API, either requesting to existing API providers or a private Server running cardano-node

example of integration:

- automatic metadata:

an object like

-----------------------------------------------------

{

message: "Hi Alice here's 50 ADA as a gift for your birthday!",

sender: "Alice's grandma",

LovelacesPerUSD: 10000000

}

-----------------------------------------------------

would be encoded directly as a CBOR map as

-----------------------------------------------------

a3676d6573736167657833486920416c69636520686572652773203530204144412061732061206769667420666f7220796f7572206269727468646179216673656e6465726f416c6963652773206772616e646d616f4c6f76656c616365735065725553441a00989680

-----------------------------------------------------

same would apply for PlutusData instances (Redeemers and Datums)

which would be converted following the ascii encoding whenever possible, therefore becoming:

-----------------------------------------------------

{

h'6d656173616765': h'486920416c69636520686572652773203530204144412061732061206769667420666f7220796f757220626972746864617921',

h'73656e646572': h'416c69636527736772616e646d61',

h'4c6f76656c61636573506572555344': 10000000

}

-----------------------------------------------------

and then encoded in CBOR

-----------------------------------------------------

a3476d6561736167655833486920416c69636520686572652773203530204144412061732061206769667420666f7220796f7572206269727468646179214673656e6465724e416c69636527736772616e646d614f4c6f76656c616365735065725553441a00989680

-----------------------------------------------------

this would be done without the need by the developer to know it even happens

- an other planned feature is smart contract usage

provided a smart contract address, something as follow would ne possible:

const myAwesomeSC = new SmartContract("SC addr");

interface RichnessParams {

howRich: "somewhat rich" | "rich" | "very much" | "jeff who?"

}

myAwesomeSC.defineEndpoint("makeMeRich", ( parms: RichnessParams ): { datum: SmartContract.Datum, redeemer: SmartContract.Redeemer } => {/*…richness code … */} );

myAwesomeSC.callEndpoint("makeMeRich", { howRich: "very much" });

the project will be open-source everyone will be able to watch the project progresses, also, major advancements will be published on Harmonic's Twitter page ( <https://twitter.com/HarmonicPool> ) like every software, a major challenge is code reliability and security. Those risks would be minimized through constantly testing the code written

project main milestones would be:

- ensuring efficient CBOR interoperability ( with JSON, PlutusData, etc. )

- sending a simple Transaction, lovelaces only as value

- sending multiasset transaction

- Minting policies interacion

- SC interaction

- Certificates management ( registration and deregistration )

- 50'000 USD as the average salary for 6 months of full-time development, ensuring project delivery AND valuing any contribution to the project itself

-15'000 USD further maintenance costs

for cost reduction reasons mainly the project will start with only one person working full-time on it

when the software will be delivered and new (possible on-chain) features will be added, having more members would be a better choice, but the on-chain part is not included in this proposal

as said before the project will be opensource, therefore Github commits will be a great way to measure the development of the project

developer and organization adoption of the library would be for sure a form of success of the project

no proposal before this one

close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00