over budget
(plu-ts) full Typescript off-chain
Current Project Status
Unfunded
Amount
Received
$0
Amount
Requested
$68,160
Percentage
Received
0.00%
Solution

Implement a 100% Typescript library to write off-chain code, minimizing dependencies

Problem

at the moment few options are available to write off-chain code, all with important drawbacks, and none supporting ts (or js) directly, which in many cases higher the learning curve.

Impact / Alignment
Feasibility
Auditability

Team

1 member

(plu-ts) full Typescript off-chain

Please describe your proposed solution.

at the moment the options to write off-chain code do require lots of extra work or are even hard to integrate for new projects

> the included video goes through some of them and exposes some arguments in support of the previous sentence

the library should allow both high-level usage and a lower one for more control;

as an example, a high-level function could be:

createDelegationTransaction(

"2a05c534817a0b97ce0c5a2354b6e35a067c52408fa70c77e0b5e378", // pool to delegate to

blockfrostQueryier // optional BlockchainQuerier to use to get data such as protocol-parameters

);

but a lower level transaction builder should still be available for personalized transactions, making possible things like:

function makeDelegationWithMyValidator() {

txBuilder.setCertificate(

makeDelegationCertificate(

"2a05c534817a0b97ce0c5a2354b6e35a067c52408fa70c77e0b5e378", // pool to delegate to

blockfrostQueryier // BlockchainQuerier to use to get data such as protocol-parameters

)

);

txBuilder.useStakeValidator(

new StakeValidator( "cafebeef" ) // will take the validator serialized code as input

)

txBuilder.setRedeemer({

bytes: "2a05c534817a0b97ce0c5a2354b6e35a067c52408fa70c77e0b5e378"

});

return txBuilder.buildTransaction();

}

Please describe how your proposed solution will address the Challenge that you have submitted it in.

the implementation of a js/ts library will, with no doubts, help the existing developer ecosystem integrate solutions in the front-end logic alongside expanding it by allowing more developers to easily use the library functionalities

What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?

the idea "as is" is nothing new (we just need a better way to use what we know is possible), so all major challenges are known and the solutions too;

regarding the implementation the main risk is in code correctness and security, this risk should be mitigated by extensive testing

Please provide a detailed plan, including timeline and key milestones for delivering your proposal.

estimated 6 to 7 months

  • safe primitives datatypes implemetation to overcome javascript limits ( 1 week )
  • examples:
  • uint64 for big integers to overcome 53-bit long javascript numbers
  • uint128 and uint256 for hashes
  • Integer class to simulate haskell variable length integers
  • HexStrings
  • etc.
  • Plutus-optimized JSON-CBOR interoperability ( 2-3 weeks )

> note: "Plutus-optimized" stands for efficent support for plutus specifics tag codes

  • PlutusData implementation ( 1 week )
  • JSON serializable object implementation ( 1-2 weeks )
  • protocol-level datatypes implementation ( 4-6 weeks )
  • including:
  • Addresses
  • Keys (private and public)
  • UTxOs
  • Assets and Values
  • algorithm representations (Linear Fee Cost-model etc.)
  • transaction-related datatypes implementation ( 6 weeks - 2 months )
  • including:
  • Metadata
  • Witnesses
  • Certificates
  • Transactions
  • etc.
  • BlockchainQueryier common interface ( 2 weeks )

> a class to help executing query againist the Cardano blockchain

  • general BlockchainQueryier implementation
  • default implementations:
  • koiosQueryier
  • ogmiosQueryier
  • blockfrostQueryier
  • etc.
  • Smart Contract interaction ( 4-6 weeks )

> NOTE: we are talking of the offchain code here, you'll need the smart contract bytecode to create instances, the bytecode is agnostic to the origin, could come from plu-ts/onchain or not

  • SmartContract class
  • MintingPolicy and StakeValidator classes

Please provide a detailed budget breakdown.

> based on salary.com stats

> ( 32 $/h * 8 h/day * 30 day/month * 7 months )

53'760 $ for 8 months full-time development

> based on the same logic of above, assuming maintainance is less intesive, covering 3 months for reference

> ( 32 $/h * 5 h/day * 30 day/month * 3 months )

14'400 $ for repository maintenance over time

> this cost is present since, being plutus a relatively new tool, the smart contract creation details on cardano are constantly evolving, the amount should cover any additional and critical development update without the need to re-create a found request for it

>

Please provide details of the people who will work on the project.

to start up the project and minimise costs (maximizing the chances of being founded) the "team" will be constituted of only one person

unfortunately, I'm not very active on LinkedIn etc.

useful links are:

If you are funded, will you return to Catalyst in a later round for further funding? Please explain why / why not.

not for this proposal, but the on-chain proposal has already some ideas for expansion

Please describe what you will measure to track your project's progress, and how will you measure these?

the project will be opensource, therefore verifiable by anyone with an internet connection

updates will be published on my Youtube channel with (possibly) weekly videos

and on my Twitter profile

What does success for this project look like?

the library has huge potential for dApp integration therefore seeing it used in various projects would be great

ideally, 2 or 3 projects with an average userbase would be a sign of adoption

Please provide information on whether this proposal is a continuation of a previously funded project in Catalyst or an entirely new one.

this proposal IS NOT a continuation of a previously funded project

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