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!

3 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!

3 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!

3 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!

4 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).

2 Likes

Hi community, this week I’ve been messing around with the TIP3 tokens, so my focus has shifted a bit, however, I was able to add the “Remove” user functionality + fixed some bugs I faced during the testing. Additionally, the transaction operations toolbar is sensitive to the transaction status, so it won’t offer the operations that are no longer available (confirm / decline for completed operations).

A few words on TIP3. TIP3 is hard. Close to the nightmare mode in DOOM2, but not yet there.

No documentation. No help in the groups. The Crystal Wallet (which is currently the only entity to implement the tokens) does not have tools to test the functionality on the DEV network as Tonscan (the web app which is the only one to display token transactions) does not support the DEV network. Finally, some brilliances in the token code itself, for example, it is not possible to compile the code out of the box even with an appropriate compiler, and after the code compiles it does really weird things.

But is was a fun week. Lots of breathtaking moments of learning new concepts. Hopefully, somebody could help me to move on with TIP3.

Let me share my findings and ideas so far:

If you want a custom token, you would need to start from this repo.

Particularly, you would just need to extend the contracts:

RootTokenContract.sol
and
TONTokenWallet.sol

Only implementing all the standart functionality would allow your token to be traded on the TIP3 exchanges, sending it to other users etc.

It sounds like a fresh idea to me to have a contract per user and per token, but well… maybe, it adds to the flexibility, we’ll see.

See you the next week!

2 Likes

Hi there, here is my update.

It’s been a busy week, and here is the list of code updates:

  • Added the cursor to transactions list
  • Added the send and receive transactions
  • Changed DeBot texts for clarity
  • Added logo!
  • Added transaction details
  • Rewrote the transaction resolve functionality on the client as it had some similarities to transaction details

The logo looks as follows:
Group 2

Check my latest working safe at: Fidosafe: Web multisig wallet with confirmations from Surf accounts (you may need to clear the cache to get the correct version, 1.0.7)

The code is in the repo.

Plans for the next week:

  • Start code audits
  • Prepare the website
  • Deploy test and prod apps
  • Submit to dappradar
  • Submit to Surf apps

Have a great weekend!

2 Likes

Hi community!

The plan for the last week is 100% ready!

New website: fidosafe.com

Test / prod apps available at app.fidosafe.com and test.fidosafe.com respectively.

The submissions to Surf and DappRadar are done and pending.

The next step would be to conduct the code audit of the contracts so that everyone can safely use them for any sums of tokens.

Collegues from the Incubator suggested the company Unboxedtype, their price is ~ 28 000 EVERs. Thus, my next steps would be to somehow get the sum.

My first idea is to set up crowdfunding, the other idea is to contact funds. If you have any ideas or want to support the project, please contact me at @Iva4599 (Telegram).

Have a nice weekend!

2 Likes

Hi guys,

I’m in progress of cooking an amazing crawdfunding page for Fidosafe, currently cannot reveal more details, but as I’m a big fan of HEX marketing, I would look forward to doing something similar, I foresee three major marketing factors:

  1. Decreasing bonus
  2. Claim program
  3. Affiliate program

The rest activities are slowly progressing, no progress so far on submissions.

With this in mind, I’m heading towards holidays, so see you the next year, Merry Christmas!
I’ll definitely update you shortly after the NY.

Cheers!

2 Likes

What if you mint your own TIP-3 token and allow people to be a part of that ecosystem? E.g. with DAO based on that TIP-3. Let say FIDO. May be I would buy some FIDO :wink:

Hi, firstly thank you very much for your support, it means a lot to me! I had this TIP3 thing in mind and even created a special website for this with some cool and attractive mechanics, check this repo (lol, it’s even in Russian), but after discussions with code auditors I decided to re-prio this item.

Notes:

  1. The current code may work funnly on huge amount of transactions (say, 100-200K), and auditors don’t want to audit it right away.

  2. Instead, they would like me to rewrite the original multisig wallet to incapsulate the logic of keeping the transactions as separate contracts (which I also find a brilliant idea since it solves the problem of storage though introducing some complexity). This would give me more chances to be audited.

  3. The current multisig contract is outdated and does not compile because it uses outdated method signatures, so firstly I would need to resurrect it.

On top of this, the product is ready, it has everything I wanted to include into it (besides some niceties like transaction history), and it is even on dAppRadar. Completely free!

Thus, to make things “truely right” will require a lot of effort, given that currently the app works “fairly right”, and because of this I would seek for the adoption first before rushing into this Solidity TON heavy lifting OR taking other peoples’ EVERs to complete the remaining 10% of haaard work.

So more ppl will use the product as is => more motivation it will give me to make the “truely right” happen. Let’s see its utilization first!

But! During my development, a very interesting idea came to me, it will be a gamify product, actually I’m currently heavily obsessed with it, I’m calculating the tokenomics, mechanics, and testing this locally.

Here is the proof:
image

Soon the website will be available, I’ll try to apply for the Broxus grant aaaaand will set up a DAO event since it would be way-way-way more complicated than the Gnosis safe. Maybe I will even start a Medium account to cater for the EN-speaking audience.

This is something I currently heavily invest my time in, and hopefully in less than 2 weeks I can share the first draft.

Stay tuned!

1 Like

Hi, I’m happy to present the whitepaper of my new GameFi idea, here it is: http://pileblocks.com/

Besides, I would like to introduce the “shouldering” mechanics to the first version of the game though it might be a controversial decision.

The idea is the folowing: the player who collects a bigger % of the whole image, grabs some bonuses from the players behind them in the line.

For example, we have 3 players, one gets 37%, the second 33%, and the last one 30% of the image.
Previously they would get their fair share of the reward amount, namely, 37%, 33%, and 30%.

Now imagine that we put them in the line ordering them by their % and start giving them bonus per tile.
The first tile gets, for example, 1 PILE, the second 1 - 1/2048 PILE, the third 1 - 2/2048 PILE, … and the last one 1 - 2047/2048 PILE = 1/2048 PILE.

Thus we have the reward decrease from 1 PILE to 1/2048 PILE throughhout the line.

This would give the first player the huge advantage since the reward melts from tile to tile, and I assume this would lead to competition for the better places in the line (ppl will start shouldering through others to get more rewards) resulting in a more active play overall.

Another promising idea would be to reject the put operation if somebody has already occupied even a single tile from your selection. This would introduce the contemplation between the greed (grab more) and fear (be on the safe side and get at least something).

What do you think about the idea in general and this approach?
@xambrella @Elsbet @Josikie @Mecubo @Gofman

Looking forward hearing from you!

2 Likes

Looks like well done product. Unfinished so far, but I like the idea. How to get in? :grinning:

I already have a picture :money_mouth_face:

Few ideas more… Would be great when the full image turns into NFT somehow once completed with many owners in accordance with pile % they have. And I see the ground for the partnership with Mozabrick as soon as this is good advertisement for them…

1 Like

@Norton, any updates. Do you already have a roadmap how to collect the money needed to cover your man / days calculation?

Hi,

Currently I’m deeply involved into building smart contracts to have something to show to investors and funds. As you can see at https://github.com/norton-1995/pileblocks, the repo contains mostly solidity code. Next week I will present my app to the Broxus team and see if I can get support from them. Regardless of the result, as soon as an alpha version is ready and I resolve all tech risks, I’m going to have a big and noisy campaign of distribution of PILE (my tip3 token) among the community.

Do you mean selling or airdrop?

Actually, I wanted both to encourage adoption :slight_smile:

Hi, I’ve lost my previous Telegram account, unfortunately, here is my new handle: @Risi1167

I’ll update all the related resources with it soon. Sorry for the inconvenience.

Hi, in case you’re curious, currently I’m writing the code which calculates the player rewards.

Please check out a random round with 7 players.
To me, the most unfortunate the situation is for player 4. The difference is only 7 tiles, and the gap in rewards is enormous. A great motivation to put some more :slight_smile:

Tiles / Reward

  • Player 1, 524 tiles, 2231.738230700 PILE
  • Player 2, 432 tiles, 1347.341094000 PILE
  • Player 3, 336 tiles, 740.164563600 PILE
  • Player 4, 329 tiles, 463.805068650 PILE
  • Player 5, 199 tiles, 155.221880550 PILE
  • Player 6, 145 tiles, 53.610741250 PILE
  • Player 7, 83 tiles, 8.117346050 PILE

Additionally, if we consider that the put price is 25 PILE and the maximum is 50 tiles per move, Player 6 should have spent 3 moves at minimum which is 75 PILE, and their reward is only 53.6 PILE.

Players 1-5, however, played profitably, noting that Player 5 did x1.5.

I wish you all the great next week!