Dev's Venture: Create a B2B web solution for managing multisig wallets

Hi, I’m obviously Norton, and as I didn’t find a better category for describing my development endevours, I would like to put it into the proposals category signifying that ultimately it is a proposal of some sort, but a special kind of proposal, a proposal to me myself rather than a request for goodies from the community. If this deserves a special category as JVs or Projects, please move it to there and sorry for my noobness (but please don’t move to dApps, it’s so lonely there).

So… let’s get started! My pitch is:

Write a Gnosis clone for freeTON.

In particular, I see it as a multisig web wallet which allows business people to manage their crypto assets as an organization. You know, onboarding employees, firing employees, assigning roles, adding weights, limiting spending amounts, limiting the timeframe to commit operations, drawing fancy reports with cornflower charts and all this corporate stuff that a typical sane and healthy crypto geek is unaware of.

Why would anybody need this?

Sooner or later busines comes to this blockchain and will require some convenient and easy to use tools to share value between parties with the necesary level of transparency and reporting.

Why does this topic even bother me?

Eh… Firstly, I enjoy learning. And my biggest confession is that I don’t know anything about Solidity,
smart contracts (eh, these ICO solidity templates to quickly create a token back in 2017 do not count) and about FreeTON (gosh, I hope for soon rebranding). Still… I enjoy learning, and the good news is that I’m not a stranger to programming in general (~14+ years of coding here and there).

When I start with a new tech, I usually code something useful and simple. Yes. Simple. Sorry, 20+ devs of Gnosis, but currently I do not see big technical challenges in the implementation. Yes, potentially a fare share of business logic and LOC, but… not a rocket science.

Yeah-yeah, mostly it is a Dunning–Kruger effect, and that’s why this topic is so important to me: To get back to it in a year and track my progress, to share my learnings along the learning curve and hopefully help other developers dive into this amazing blockchain and create more exciting dApps and services.

I’ll try to commit to updating this thread at least once a week and sharing my progress and concerns. It will keep me delivering and fighting procrastination. Of course, all my code will be publicly available and under MIT. Please note that I have a 9-to-5 job and this project is my hobby, so don’t expect a Ferarri speed.

Still, I’m not sure if this is the right format and the right forum for sharing such stories. If all good, I’ll update you the next week. If not, most likely this topic will be removed :slight_smile:

The next time I’ll share my thoughts on the implementation and post the first bunch of helpful links I’ve received.

Anyway, good luck and happy upcoming week!

2 Likes

Hi community! I spent this week poking and probing and asking for help in Telegram groups. Although the majority of ppl there communicate between each other in Russian, I received well-structured answers to all my questoins. Kudos to the community!

Groups:

Special thanks to @EkaterinaPantaz for guiding me through the initial set of specs and sending links to the code where ppl do similar things to those I want to build.

I used the following helpful references to get started:

Some notes I did along the way:

  • The current compiler version 0.51 is not compatible with the debot samples, so you would need to downgrade it to 0.47.0 compile them. More on how to do it here.

  • Lots of deploy scripts refer to tonos-cli as ./tonos-cli which does not work with my version of bash, it requires just tonos-cli call.

  • The process of storing and receiving data from TvmCell and TvmSlice structures is not well documented.

In practice, it looks as follows:

TvmBuilder builder;

// Here we can pack values N times
builder.store(address.makeAddrStd(0, 0x66e01d6df5a8d7677d9ab2daf7f258f1e2a7fe73da5320300395f99e01dc3b5f), uint16(123), 'asd');
builder.store(address.makeAddrStd(0, 0x66e01d6df5a8d7677d9ab2daf7f258f1e2a7fe73da5320300395f99e01dc3b5f), uint16(321), 'dsa');

// Store them in the state by transforming them to TvmCell
TvmCell message = builder.toCell();

// Receive the cell in the processing function
TvmSlice slice = message.toSlice();

// We decode N times to unpack our data
(address addr, uint16 val0, string val1) = slice.decode(address, uint16, string);
// val1 is "asd"
( addr,  val0,  val1) = slice.decode(address, uint16, string);
// val1 is "dsa"
  • If a function returns a string, the string is hex.

All the rest went smooth, everything worked / compiled / run really well.

So what is the actual progress?

The awesome news is that now I have a high-level vision on how I see my system. Let’s assume, all the contracts are deployed, then each operation will looks as follows:

I didn’t check the web SDK yet, but highly likely it would be a read-only and not-that-complicated stuff. For the rest, I confirmed that all the parts of the system are feasible.

Why Surf and debots? As an alternative, there is a ton-inpage-provider library which integrates with the TON Wallet Chrome extension, but it has only ~ 2000 installations, so Surf now has by far better adoption and traction.

Here is the info about constructing a link and a working example.

The plan for the week is to create a POC with some operation being performed through the web, confirmed from web/mobile Surf, and being reflected on the web.

Currently I do not touch the question of deploying multisig contracts as it was pretty much covered in this example. So let’s assume we have the DeBot and the contract, and we want to do smth from the web and confirm this from our cosy Suft Wallet taking into consideration multiple custodians involved in the operation.

Cheers!

2 Likes

Hi, finally I would share some code and great news!

The code is at:

If you run it, you’ll see something like:

Actually, this is nothing more than a simple web app which triggers a get method of a contract. The contract itself is the first version of our DAO / multisig.

At the heart of the contract is Transaction which accompanies any operation requiring multi-user confirmations. Currently users (admins) can (together):

  • Create other users
  • Change the number of confirmations each operation requires

Nothing fancy, but it paves the way to my idea: create a multisig web app with confirmations from Surf and with the business account applicability.

… and the news is: I would like to refine my idea a bit.

The pivot is to create a collective investment tool (safe) for ordinary users to get a better passive income than from farming.

WIN for users: Ideally, users yield more than stable farming % with no hassle of FOMO.
People trust their funds to professional traders/investors with a guarantee these experts collaborate with each other and make transparent thoughtful collective decisions (like a good-old brick and mortar asset management but with multisigs). User funds are locked with the ability to claim 1 week per quarter to prevent panic actions (the cause for the majority of money loss).

Experts are very limited in what they do: They can only swap some sum of crystals to a token and back (so no transfers to malicious accounts). Surely, they can also confirm/reject other admins’ operations.

WIN for experts: They receive remuneration of 15% for their services (from the profit) paid 1 week quarterly. They manage other ppl’s money and get reward if they do it good. Classics.

WIN for me: 0.5% from each transaction accumulates in the project wallet with the possibility to create a token and build up own unit economy.

Anyways, I’m at the very beginning, and would be curious to hear back from you. Cheers!

2 Likes

Hi, I would like to apply for an Everscale incubator program, so in this post I want to firstly recap on my goals and milestones.

Goal 1. Create a user-friendly, convenient and flexible web multisig wallet with confirmations from Suft accounts.

This is my current goal I currently work on. Here are the details on my vision:

  • User-friendly: Intuitive UX, avoid using console / manual operations / debots if possible. Users configure operations and view the results through the web UI.

  • Convenient: Users do not need to create new accounts to use this multisig, they confirm operations either from the web or mobile version of Surf.

  • Flexible: Users configure the multisig on the go adding and removing users/configurations as necessary keeping in mind the voting nature of making decisions.

On this note, here is my weekly progress.

1. Styling refinement and general representation of the app interface. Here is how the main page currently looks like:

2. General workflow of confirming operations:

3. Debot to deploy a safe:

3.1. Fund an account.

3.2. Deploy a safe.

3.3. Check the result on the web.

Code is as usual at: fidosafe / fidosafe-web · GitLab

The code is a bit messy, I would like to brush it up the next week. For example, move the Everscale API to a singleton under a Vue instance and better structure the deploy scripts. Afterwards, I would like to add a state-changing operation, for example, add a user.

Goal 2. DAO which lets users have better income than from conventional farming by trusting their tokens to professional investors / traders.

This DAO will base on the FidoSafe architecture, but would be more complex in terms of roles and functionality. The most complex parts would be related to calculating user and investor rewards and periods when they can be claimed.

I would like to complete Goal 1 first before getting into details on this one, but all and all the general idea should be clear.

Have a nice weekend!

2 Likes

Hi, do you remember that tangled diagram from my update #2? Now it works, box by box, arrow by arrow!

Check out the following video.

In this demo I have an existing Surf account, and firstly I create a safe and then add another user to the safe using Surf confirmations. Btw, this works from mobile as well using QR codes.

The code is moved to Github

… and I did some code cleaning.

Thus, the POC is ready, so the only thing left is to complete the business logic. Easy! Btw, the current safe version is available at https://fidosafe.com, so you can try on your own.

P.S. Changing the number of confirmations also works. But. Currently you won’t be able to move them back, beware!

Next on the road: the transactions & confirmations page.

Have a nice week!

2 Likes

Hi, it’s been a busy week, I’ve added the transactions to the mix, please check the result (my existing safe at dev). I’ve also shared my plans and progress at the Everscale Incubator podcast yesterday, I’ll attach the YT link of the record once it is published.

The next week plan: users removal and start shaping the web app into a product (add help texts, add validation and the other boring and necessary stuff).

1 Like