Thread by @juanjoarl

_OVERLEDGER PRODUCT RELEASE ANALYSIS_

Today we start with a new type of thread! 🥳🥳

Welcome to the #Overledger_product_release_analysis, a periodic analysis of the new updates, implementations and programming sides of the releases uploaded by @Quant_Network

So, let´s first begin giving a little introduction to the Overledger Product releases. As the name says, these are updates given by Quant to the community. They englobe or resume the new implementations/upgrades/improvements/fixes made to Overledger.

quant.network/overledger-rel…

By the way, you can stay up to date with these new publications through our friends at @QuantDevelopers , they post the news much faster ⚡️ than Quant's page itself. 😎

As I was saying, these threads would be focused in the following points about the releases given periodically:

- Analysis of the new features added 🔧
- Programming examples of the implementations 👨🏼‍💻
- Specific usecase examples 👷🏻‍♂️

The first thing I want you to do before starting is to read the first two sections of the PDF.

Just the "What´s new" and "What this means for you" sections, they are short and easy to understand 😁

Here you have the PDF --> developer.quant.network/docs/Quant_Ove…

We would address the following Key points:
• Introduction of MFA (Security) 🔐
• ERC20 support on Goerli testnet 🚰
• Monitoring functionality 🕵️‍♀️

Follow me... 👉🏻 ....🚣🏻‍♂️ 🌊🌊🌊 🏰

1 - INTRODUCTION OF MFA:

Our friends from Quant Network have just added a new security feature in our Quant´s accounts. As you just have read, from now on you would be asked to setup your 2FA or MFA.

Just download your favourite auth APP and follow the given steps.

2 - ERC20 SUPPORT ON GOERLI TESTNET:

The technical team of Overledger, as they have released new implementations of DLTs such as Goerli, Polygon, Xinfin or Avalanche, have also deployed test tokens so that we can play with them.

Deploying contracts or faucets on test networks is a fairly common practice. It allows developers to play around and test with tokens that have no actual value.

Here you have the Goerli-etherScan link:
goerli.etherscan.io/address/0x8cFC…

🛑WARNING🛑

Connecting your metamask or interacting with unknown Smartcontracts can be very dangerous. Most current HACKS occur through malicious smart contracts that infect our account. Accepting a malicious transaction can be very costly and put your tokens and privacy at risk

3 - MONITORING FUNCTIONALITY

Overledger has multiple "public" funtions:
- Transaction creation (Native, ERC20/QRC20, ERC721/QRC721)
- Transaction and Smartcontract search 🔎
- SmartContract Invoke...
- Resource Monitoring ... 🔵
- Etc...

We can imagine it as a giant factory, which has many postboxes.

Each of these postboxes 📬 has a unique address, and the letters or requests that falls into them are also redirected to unique departments.

We send instructions to them through API calls. 📩

Today we are just going to interact with the blue department, the QRC20 Monitoring functions.

Stop a second and think with me ... 🤔💭

What is as important as being able to SEND transactions or Invoke SmartContracts?

⏳ ... ... ... ⌛️

That's it!

It´s as important to be able to KNOW that our specific action has been SUCCESSFUL or has FAILED (Feedback)

This department specializes in detecting events within blockchains. Knowing if a token has been minted, burned, transferred, or if a new owner has been added 🤝

If you take another look to the PDF, you would see there are 4 new QRC20 functionalities:
1. Mint Token Event Subscription 👈
2. Burn Token Event Subscription 👈
3. Add Account Event
4. Transfer Event from Secondary Owner

We would get into the first two functionalities (The rest would be addressed in following threads 😁 )

As you can probably infer, Overledger has a set of features solely focused on monitoring all kinds of resources in different DLTs.

Overledger allows us to practically monitor any type of events and interactions with addresses, smart contracts, and the data/tokens they handle.

We can achieve this monitoring processes through different methods.

We can monitor, let's say, manually, or through processes specifically created by Quant to facilitate and improve the experience.

We can use the green or blue paths, both would end in the same function. One is the hard path (Blue) or the pre-made path (Green)

Our new release functions fall into the green path, they are made to shortcut some technical and difficult aspects.

In our PDF we can see the following commentaries.

The purple one shows us the API address (PostBox) to interact with the SandBox (Testing).

Once we have Deployed our contract (QRC20 Tier2) through the Connect-Quant-Tokenise website, we can begin to monitor and interact with them 😎

connect.quant.network/tokenise/deploy

Let's dive into some code.

What you can see in the image attached is the "letter" we would send to the QRC20 Mint Monitoring API.

- We specify the DLT tech and location were we have deployed our QRC20 Token.

- We specify the URL/address were I want Overledger to send the info every time the event takes place. I use a web called pipedream.
- Type of event --> Mint Tokens/Burn Tokens
- TokenUnit --> Name of our QRC20 token (Only works with QRC20 tokens)

So let's send it though the API and we obtain the following answer.

We can see that now we have a field that contains the SubscriptionID for our specific Monitoring Event and Token.

This is used to handle multiple monitoring events.

Now our token is being Monitored ✅

Here we have a diagram that explains the process

Now we mint some tokens through the API and look in our POSTBOX (Pipedream Web page) to see if we get any answer from the Overledger detective that is looking our token.

This is the instruction we send to the OVL QRC20 Mint API.

OVL response for the Mint petition. 📩📩

We sign it with our private key and the OVL signing library. 🔏🔏

The TX loaded with the Mint Instruction is inyected in the DLT and aimed to our QRC20 Smartcontract 🎯🎯🎯

Now we take a look in our PipeDream end-point (PostBox)

We can see the answer contains all the sensitive info we need for future actions in our "Traditional Program".

So to conclude.

We have just seen the process of how an Event Monitoring is setup and how we recieve an extensive answer with all the data about the tx that triggered the Mint Event.

This kind of functions are basic for programmers in order to create complete software for DLT interaction purposes.

We could easily add this function in the USE CASE we designed in the previous Programming Thread.

When the Tokens are BURNT, OVL Monitoring system detects the EVENT and continues with the next steps to give the Chefs the green light for making the Burguer.

Thanks for reading this long thread. Hope you have learn something new and had a good time with these new Releases Analysis.

Give some love if you liked, lot's of work and love have been put in this thread ❤️

Keep rocking guys🔥