GeoDB Coin ($GEO) — Bonding Curve Token Offering II

Technical Approach

1.- Introduction

GeoDB is a decentralized data sharing platform in which each individual piece of information is provided by the users themselves, under their own knowledge, being validated and proved by them and confirming to any interested buyer that the information comes directly from the source of data that generates it.

To do the above, GeoDB brings to the community a solution that is supported by a wide technological stack that relies on public, private, and federated tools. And among these tools, a subset of them stands out, and they are the DLT tools, which allow GeoDB to offer a completely unique information network and marketplace in which each of the participants obtains unique advantages.

2.- Technical Approach

Blockchain or DLTs (we will use both terms interchangeably, being ​DLT an acronym for ​D​ecentralized L​edger ​T​echnologies) are possibly one of the most elegant technical proposals conceived by mankind to solve an inherently complex problem.

These technologies are based on an absurdly simple idea, to make several entities keep a copy of all the information in a network. Although at first, it may seem that this does not provide great added value, we quickly realize that this allows us to provide solutions that expose unique features such as the immutability of information, transparency in operation, or the removal of centralized elements in governance.

But we must not fall into the error of confusing the basis of the technology with the technology itself, because even though the basis is simple, having this common copy of information among the participants while ensuring their correct behavior, is a highly complex and exciting technological challenge.

DLTs combine distributed computing techniques with cryptography concepts and game theory ideas, where proposals are materialized in concise solutions that are the result of a deep analysis in which the aforementioned elegance lies.

For this reason, when analysing any proposal in this field, it is advisable to reflect on both what one wants to do and how one wants to do it. In this section, we will try to offer a guide to the reader that will help him/her to make this reflection in our case.

We will start with the first element, our token, the $GEO. The $GEO is an ERC-777 utility token that is backward compatible with the ERC-20 standard. What does this mean? That it brings together the best of both standards, with additional features over the ERC-20 standard that make it safer and easier to use and can be seamlessly integrated into any solution developed for the ERC-20 standard.

Most DeFi solutions are being deployed on the Ethereum network and, in order to make them compatible with as many existing tokens as possible, almost all are focused on the use of ERC-20 tokens, which makes the range of solutions we can use in our proposals, either through integration or adaptation, extremely wide. Even more importantly, the availability to use multiple solutions will make our proposals much safer, which is an extremely critical element to consider as our technical analysis progresses.

DLT solutions are robust, and huge amounts of money move around them. Users, often lured by siren calls of cryptography and its virtues, sometimes get carried away by the general enthusiasm around a given proposal. In general, a DLT solution is much more robust than a non-DLT one, but it is not always so, and a poorly designed solution can lead to catastrophic and irreversible consequences. That is why we must try to advance on the shoulders of giants and try to use, whenever possible, those solutions that have been analyzed and audited by third parties.

As users of DLT solutions, we have the enormous advantage of transparency, whereby everything is reflected, immutably, in the public domain. This allows the community to quickly become aware of flaws and propose new solutions that solve and/or mitigate them, the ecosystem security growing increasingly safer as time goes on. And yes, DeFi protocols, even in their initial stages, have already been exposed to different problems that the community has been able to face and solve, from which safer and more resilient solutions have emerged. To be up to date with potential problems we refer the reader to the following link ​https://defirate.com/hacks/​.

We talk openly about this because we believe that the most intelligent approach to building a secure solution is to put special emphasis on potential attack vectors, avoiding the incorporation of any element that does not offer full guarantees to its users. Therefore, as a rule of internal self-regulation, in the most critical and sensitive elements, we ensure that we only use tools that have been audited and previously tested in other projects.

Starting from a set of audited tools and using our ERC-777 token backward compatible with the ERC-20 standard, let’s take the first step that will allow us to advance in the proposal of our DeFi strategy, the deployment of a bonding curve smart contract in Ethereum that allows for the distribution of $GEOs.

A bonding curve smart contact is simply a smart contract for the distribution of a certain crypto token, which is acquired by exchanging a required counterpart at a fixed cost given a predefined curve. Thus, by establishing a bonding curve smart contract in which the $GEO is the main crypto token and ETH is the required counterpart, anyone can exchange ETH for GEOs.

At the time of deploying a smart contract of this type, the developer is free to provide it with as many characteristics as he/she wishes, from the shape of the curve that will determine the cost of each token, the nature of the accepted counterpart, initial and/or final prices, the number of tokens available for distribution, the minimum or maximum quantity of tokens to be acquired in a specific transaction, and many other aspects.

We will now review the decisions that have been made by our team in order to deploy our bonding curve smart contract which, for the sake of brevity, we will refer to hereafter as the bonding contract.

a.- General approach

In the previous lines, a strong emphasis has been placed on the need to provide a solution that is as safe and resilient as possible, and this begins with a strong self-restraint in our proposal. The fewer features supported, the less risk there is of an attack vector surfacing. Following a lean approach, we focus on the minimum proposal that allows us to do the above in an extremely secure way.

In addition, with our distribution offer, we seek to capture the general behavior of investors in such a process, as well as grant a discount to those who participate at an early stage in order to have a fast, dynamic and equitable distribution. The curve used in the bonding contract will be modeled to maximize this behavior.

b.- Shape of the curve

The shape of the curve determines the cost of each individual token that is exchanged as the distribution progresses.

If we look at the ​X and ​Y axes of the following graph, ​Y​i represents the amount of currency ​Y to be sent to the contract to acquire the ​X​j​ token.

The most trivial bonding curve is one that is modeled by a constant function in which all tokens have the same price, P, and the acquisition of a quantity, C, of tokens is computed simply by the product P*C.

A typical way to model a bonding curve is by means of an increasing linear function, in which each new distributed token will always require a larger counterpart than the previous one, being this increment equal to a fixed value, that is, being Xi, Xi+1 and Xi+2, three consecutive tokens to be distributed and Yi, Yi+1 and Yi+2 the three corresponding counterparts, it is fulfilled that, (SA) Yi+2>Yi+1>Yi and that (SB) Yi+2-Yi+1=Yi+1-Yi for all i in the domain [0, T-2], being T the number of tokens to be distributed.

Although in this case, it would be possible to manually define a simple formula to compute the cost of a number of tokens, in those cases where the function is not constant it is usual to model the cost by integrating the bonding curve in order to compute the area contained under it. Ultimately, it will be the computational complexity required to calculate this value, that will lead us to define the cost computing function, since the amount of gas that the user will have to use to operate with the bonding contract will depend on this complexity.

When we previously introduced increasing linear functions, we have noted the statements in the mathematical formulation by SA and SB.

SA determines curve increment, that is, that each token requires a larger counterpart than the previous one. When talking about increase we must differentiate in turn between increasing functions and strictly increasing functions. In a strictly increasing function, each token will require a larger counterpart than the previous one (as in SA), while if a token could require a counterpart equal to the previous one (although it could never require a lower counterpart), the formula is slightly different (SA’) Yi+2≥Yi+1≥Yi.

On a practical level, the difference between a strictly increasing curve, SA, and an increasing curve, SA’, is that the latter may have plateaus, which, leading to the distribution of tokens, may be desirable (in case we want to encourage a specific behavior).

SB is the statement that determines that the increase is constant, and it is easy to deduce that it can only be fulfilled if the curve is strictly increasing (SA).

Focusing on our specific case, we have explained that we want to encourage a certain general behavior of investors, as well as provide a discount to early participants. Translated into a specific curve shape, we speak of an increasing function (SA’) with an initial logarithmic behavior, a central plateau, and a final exponential behavior.

Although the above would be easy to model using a piecewise function, we must consider that the use of this kind of functions would result in higher computational cost, thus a higher gas consumption for users, so we must bet on a more efficient approach. We must, therefore, opt for a strictly incremental function (SA) whose shape will be similar to the desired one.

Among the plausible options to do the above, we have analyzed the pros and cons of the three options:

(i) Use the logit function (or the probit function) normalized in the range [0, 1] for curve shape adjustment. This function exposes the desired behavior in its extremes, that is, an initial logarithmic growth and a final exponential increase, being the central increase more pronounced than in other alternatives. Logit and probit functions are widely used in linear regression and in fields such as artificial intelligence, Bayesian logic or economics. Their formulation is extremely simple (log(x1-x)in the case of the logit function), which makes them easy to understand. In contrast, their adaptation to model our curve would admit less flexibility and their integration and consequent computational cost would be higher.

(ii) Use a polynomial function with different degrees. With them, we can do practically anything we want, but in return, their integration could result in an extremely expensive formula to compute (which would lead to high gas consumption in each transaction).

(iii) Use an odd degree polynomial function normalized in the range of values in which we want the token price to move during its distribution. Odd degree polynomial functions give values below 0 for negative values and above 0 for positive ones, being their variation as they approach zero smaller and smaller. Therefore, they present a shape very close to the one described above, with the advantage that their integration is simple.

In order to minimize transaction costs, we decided to develop our bonding contract following the third option, that is, using an odd degree polynomial function. Specifically, we will use a cubic function, as values higher than three would suffer from very pronounced increases in their extremes.

Once the above has been decided, all that remains is to adjust the function x³ and carry out the integration of the adjusted function, but first, we must explain why it is necessary to operate by means of integral calculation.

In our previous explanations, we talked about the bonding curves and we explained that they reflect the individual value of each token, but for simplicity, we have treated these values as if they were discrete values. In practice, we must understand the curve as the evolution of the price form a point Xi to a point Xj therefore, the cost of acquiring a quantity C, when the curve is at Xi, where C=Xj-Xi, can only be computed by calculating the area contained under the curve, the reason why we need to compute the integral function.

That is, let’s suppose a linear function which at 0 has a value of 1 and at 1 has a value of 2. If we acquire the first token this will not cost us 2 monetary units. The cost of this token will be given by the area under this curve, for this example 1.5 monetary units.

With this in mind, it is time to ask ourselves how we can adjust x³ function for our bonding contract and how to compute its integral function.

Let’s consider that we are going to distribute 1000 tokens, starting from a price of 0.5 monetary units and going up to a price of 2 monetary units. Let’s do the following computations:

1. Divide the number of tokens to be distributed in half to be able to move the function to the right.
2. Adjust the ranges of the function so that it starts at 0 and moves in the set range of monetary units (2–0.5=1.5).
3. Add the desired value on the plateau to the result and that’s it.

Translated the above into concrete values we have:

Which allows us to compute the bonding function:

Bonding(x) =b(v-a)³+c

Now, we compute the integral function and we have:

From which we can compute the following function that would allow us to compute the cost between xi and xj.

Note that the values a, b, and c are constants with values 500, 1.5/250,000,000, and 1.25 in this case. So we instantiate the previous function before operating with it:

Obviously, the previous values should be instantiated in the bonding contract itself according to the values established in the deployment, so the previous function should not be taken as final and it is only instantiated to illustrate this example.

The above function allows us to compute the number of monetary units needed to acquire a given amount of tokens, that is, it allows us to launch purchase orders by setting a limit price to be paid for the number of tokens to be acquired.

In order to support market orders which allows us to spend a specified amount of monetary units in order to buy the maximum amount of tokens when the transaction is executed, it is necessary to compute the inverse function of the previous one, that is, given a number of monetary units we want to know the number of tokens to be bought.

Operating on the previous function we obtain the following quartic function:

Note that we’ve generalized the function considering that the purchase order is the first order executed during the distribution process. It is trivial to prove that, at a starting point greater than 0, the result is given by the difference between the two points.

We now make the following substitutions:

And we substitute in the previous function:

Find the root of a quartic polynomial is not a simple process and requires very convoluted formulas.

In order to apply the resolution function, we first divide the current function by 𝛂 to obtain the following values:

and we would have the following polynomial:

To apply the resolution methods, we make the following substitution considering that a’=0 and b’=0.

Through the above substitutions we can compute the four roots as follows:

As we have that k=x-a, we substitute again and we have the solutions in x.

Through different experiments we’ve determined that the result that would apply for the relationship that our coefficients keep between them would be the one given by x2, therefore, the root to consider will be:

If we now substitute the previous values we have:

As can be seen, the function is highly complex if it is expressed in this way, which is why it is more optimal to compute it using the substitution values and operate directly with them using the previous function.

c.- Operation of the bonding contract

We have an ERC-777 token and a function to model our bonding contract, so all that remains is to decide the features and limitations for operating with it. Let’s keep in mind that previously we emphasized the need to keep contracts simple in order to minimize potential attack vectors that may entail certain risks for our investors.

We detail below the decisions made by our team, briefly justifying some of them if necessary:

1. There is no limit to the number of $GEOs that can be purchased from a single address during our Bonding Curve Token Sale (Limits are only set in our Pre-Sale 1 and Pre-Sale 2). In a centralized distribution offering it is usual to establish a minimum threshold given the need to carry out KYC and AML processes for each user. On the other hand, sometimes it is interesting to limit the maximum number of tokens that can be acquired by a given user to avoid the appearance of “whales”. As this is a purely decentralized process, it is senseless to limit any of these values since there is no additional workload for our team nor is it possible to prevent a user from participating several times using different addresses.
2. $GEOs are received by the buyer at the time of purchase: Automatic Settlement.
3. The necessary counterpart to participate in the distribution offering is ETH.
4. The ETH sent to the bonding contract will remain there until it is transferred manually to the Uniswap liquidity pool (25%), to the company’s DeFi funding wallet (25%), and finally to the company’s general fund account (50%). This process could have been automated, but it would require higher transaction fees for users.
5. The liquidity pool will be available shortly after the end of the distribution offering.
6. There are two ways to end the distribution offering, (i) distribution of all $GEOs in the contract and (ii) exceeding the time threshold. Numbers for the adjustment of these values will be indicated in our next post.
7. The return of $GEOs to the bonding contract is not allowed. Transactions can’t be canceled or reversed.

d.- Pre-sales

Prior to the distribution offering using the bonding contract there will be two decentralized pre-sales at a fixed price.

An investor will send ETH to the contract and he/she will get a fixed amount of tokens in exchange.

However, there are significant differences between the operation of these pre-sale contracts and the bonding contract of the general distribution offering:

1. A lower and upper limit of ETH to be spent using the same address is established in each pre-sale. The limits of each pre-sale are indicated in the next section.
2. The duration of pre-sales is limited. They will only be open for a few minutes/hours. Time windows are indicated in the next section.
3. Purchases in pre-sales 1 and 2 have 6 and 3 month lock-up periods respectively. Two special ERC-20 tokens with a 1:1 peg to $GEOs are issued for this lock-up. The buyer will be able to transact with those special tokens using any ERC-20 compliant application such as Metamask, but will not be able to trade or transfer them prior to lock-up expiration. Once this lock-up is over, tokens can be transferred to any Ethereum address, special ERC-20 tokens will be burnt and $GEOs released.
4. Any investor who participates or tries to participate in pre-sale 1, by sending an amount greater than or equal to the established minimum purchase, during the set time window, will be automatically whitelisted for pre-sale 2.
5. Prior to the opening of pre-sale 2, there will be a time window during which, any whitelisted address in pre-sale 1, will be able to issue a purchase transaction that will be executed at the beginning of pre-sale 2.

e.- Smart contracts

There will be a minimum of 5 smart contracts deployed in the process namely, (i) pre-sale 1, (ii) pre-sale 1 lock, (iii) pre-sale 2, (iv) pre-sale 2 lock and (v) bonding contract.

The code of these smart contracts will be available from both Etherscan and GeoDB’s website for review by any interested party. Additionally, any auditing process carried out by third parties will be made publicly available.

f.- Additional tools

Although the entire process is decentralized, a web portal is being developed to facilitate operations, from acquisition in different phases to the progress of each one of them, as well as visualization of operations with lock-up tokens.

This website will be released in the next few days.

For further updates please visit: https://geooffering.geodb.com/

Our full DeFi paper is available here: DeFi Paper

And finally, you can join the conversation in our Token Sale Telegram channel.

Thanks for reading, we will come up with our offering phases and conditions tomorrow. Enjoy the day!

The GeoDB Team.