Writing to the state of the smart contract.

This page explains the functions used to operate that smart contract and is followed by the explanation of reader functions of the smart contract which are view functions in solidity. This page covers functions like transfer and mint functions that essentially change values and do not meet the rules below.

View functions ensure that they will not modify the state. A function can be declared as view. The following statements if present in the function are considered modifying the state and compiler will throw warning in such cases.

  • Modifying state variables.
  • Emitting events.
  • Creating other contracts.
  • Using selfdestruct.
  • Sending Ether via calls.
  • Calling any function which is not marked view or pure.
  • Using low-level calls.
  • Using inline assembly containing certain opcodes.

For now please read from or listen to this page to get familiar with the logic of the smart contract so you can make informed decisions when controlling your wallets Wealth Architect Value. These are the write functions that can change the state of the contract ordered chronologically.

Contract Setup(1)

Step 1(Contract Creator).

When this function gets called, it sets the first admin. It cannot get called ever again for the sake of security, allowing a single entry point along with zero constructor arguments. In simpler terms, it’s easy.

AdminInitialSet()

Step 2(CEVA and Admin).

The function sets up a struct of values representing the admin-controlled wallets that collect the transfer fees for the different organizations operating the Exist Family of entities.

L fee wallet secret ID is the Variable that sets the array key of the using a bytes32 encoded secret for this group of fee wallets.

Each address here represents the wallet receiving equity, the equity rents fees described in the digitization bundle, equity rents agreements section.

asetFeeWallet(

          bytes32 _LfeeWalletSecretID,rents agreements section.

          address _whoaaddress,

          address _whoamaintenanceaddress,

          address _whoarewardsaddress,

          address _cevaaddress,

          address _credibleyouaddress,

          address _techaddress,

          address _existholdingsaddress,

          address _existcryptoaddress)

Step 3(Admin).

You have a privilege level of 4(admin). You can use this function to set the fee Wallet secret of the entire contract and change a fee wallet group to collect too. Using this function, we create security in the case of compromised addresses.

setFeeWalletSecret(

bytes32 secret)

User Setup(2)

Option 1(User).

Any ethereum wallet can set its user privilege level to zero, initializing its account on the Wealth Architect With Escrow Smart Contract. Users must set all wallets intending to interact with the smart contract. Wallets that have ONUS transferred to them through the transfer function get automatically set and contributors for escrow agreements.

asetMyUser()

Option 2(CEVA, Founder Developer, and Admin). 

Using this function, you can set the privilege level of users that are 1 level lower than you are. i.e., Founder Developer is level 2 and can set level 1 members and level 0 guests. Admins can use the function to define the addresses of a user’s founder developer one and ceva, set user privilege level, and they get to set other admins. Use the Buy Founder Developer License Function once a member to get your first founder developer account. Additional wallets can get awarded to founder developers with whole level two privileges(founder developer) upon approval. Approval depends on use and intent as well as track record. The primary benefit of this function is to set up CEVA accounts and Admin accounts.

asetUser(

address _UserAddress,

address _Ceva,

address _FounderDeveloperOne,

uint 8 _UserPrivilegeLevel)

Property Minting/Burning Setup(3)

Step 1(CEVA).

Using this function, we can set the original MetaData that makes it possible to mint tokens and create escrows for a property getting annexed into WHOA. Only a user with a privilege level of 3 or higher can use this function. The variable bool set turns the property on or off with a true or false value. Address Founder developer sets the address of the founder developer that is digitizing this property, and Address owner sets the address of the property owner. Address hold one sets the address that will receive the equity rents shares for the hold one envelope created for this property. Address hold two sets the address that will receive the equity rents shares for the hold two envelopes created for this property. Address three sets the address that will receive the equity rents shares for the hold three envelopes created for this property. U int 256 value sets the property’s value with a number to verify against and use as a baseline value for the tokens getting minted to the property. U int 256 number of tokens to escrow gets used to set the number of single tokens to escrow on this property for options, debt, and development. Bytes 32 property I D set the property I D of the property with a bytes 32 encoded string value and is used as the array key to reference the property throughout the contract. CEVA can retrieve all of this information from the users’ paperwork or account, to which CEVA has access.

asetProperty(

          bool _Set,

          address _FounderDeveloper,

          address _Owner,

          address _holdOne,

          address _holdTwo,

          address _holdThree,

          uint256 _Value,

          uint256 _NumberOfTokensToEscrow,

          bytes32 _PropertyID

          )

Step 2(CEVA)

Using this function, CEVA privilege level addresses can set their working property ID to burn properties tokens. To call without failure, enter the property ID of the property you will be burning and have a user privilege level of 3 or higher.

aCEVASetWorkingPropertyID(

          bytes32 _PropertyID)

Step 3(CEVA)

Suppose that a property has met all of its goals, for example, was purchased, cleared of its (debts/senior encumbrances), and developed to its highest and best use. To remove the tokens from circulation, CEVA must set their working property ID using the “A CEVA Set Working Property ID” function to change their wallets working _propertyID. Enter the property’s current value and the property owner’s address in the “address clear from” field, then call the function. The function will only be successful if the CEVA wallet address burning the property contains the ONUS’s value that the owner doest control in AVEC on the property. When the CEVA privilege level address calls this function, that address is buying the funds being delivered with ONUS that the owner no longer controls. The property will freeze in value, and the other AVEC token holders will be able to move their funds out of the property. Still, once removed, the smart contract will accept no new conversions from AVEC into ONUS on this property.

aBurnProperty(

          uint256 _propertyValue, 

          address _clearFrom)

Property Minting(4)

Step 1(Founder Developer).

Users with a privilege level equal to or greater than two can mint AVEC using this function. Once approved by CEVA using the A set property function, a Founder Developer with a privilege level two address can call this function to mint avec on their latest property. Just set the founder developer fee number between 20001 for the highest fee, 4.999 percent, and 100000 for the lowest 1 percent. Once called, if CEVA has completed an approval and property setup, it will automatically distribute the Founder Developer their minting commission as ONUS along with all other associated fees up to 8.999 percent to their intended wallet addresses. The property owner will receive the remainder of tokens available on the property that CEVA did not reserve for an escrow agreement; if no tokens got reserved for escrow, the home-owner would receive the total amount minted minus the fees. Once this function gets called, the minting is complete, and tokens get distributed.

afounderDeveloperMintAVEC(

uint256 _founderDeveloperFee)

Escrow Agreements(5)

Step 1(CEVA and Admin).

When creating escrow agreements for a property, Contributors must complete each agreement before CEVA can make the following agreement; otherwise, the following arrangement will override the initial escrow. Bytes 32 Property ID sets the property id used to index the escrow agreement, address payable recipient Of Funds sets the recipient address that receives the ethereum funding from the escrow once the funding is completed, bytes32 recipient Name sets the bytes 32 encoded string representing the name of the recipient, uint8 escrow Agreement Number is used along with override to select a previous escrow agreement and adjust its information based on the escrow agreement number, bool override set is a true-false value indicating whether CEVA gets to override a prior escrow agreement or not this is included for particular use cases, bool escrow Completed set the true-false value indicating whether the escrow funding was completed or not used for overriding old escrow agreements if they never fund to release funs to the recipient address, uint 256 milestone Price Of Escrow In E T H sets the amount of Ether required to consider this escrow agreement number as funding completed = true this releases the funds to the recipient once the total amount contributed has reached an equal amount, uint 256 tokens Available Total sets the total number of tokens available for release on this one escrow agreement to be compared against the contributions and distributed based up that, and U int 256 property Increase sets the amount of an increase to apply as a value adjustment using the adjust property value function by ceva.

createEscrowForProperty(

          bytes32 _PropertyID, 

          address payable _recipientOfFunds, 

          bytes32 _recipientName, 

          uint8 _escrowAgreementNumber,

          bool _override,

          bool _escrowCompleted,

          uint256 _milestonePriceOfEscrowInETH, 

          uint256 _tokensAvailableTotal,

          uint256 _propertyIncrease

          )

Step 2(User).

To contribute to the escrow agreement for a property, send ethereum value to the contract using this function; enter the property I D of the escrow agreement, the amount you would like to contribute, and call the process. Once the escrow is funding complete and the recipient gets their funds, you will be able to use the “withdraw avec from escrow” function to claim your portion of tokens.

function contributeToEscrowForProperty(

          bytes32 _PropertyID)

Step 3(Recipient).

When you know that an escrow agreement is funding complete, you get to withdraw your tokens from the escrow agreement; enter the property ID you would like to draw from, and it will deposit directly into your wallet when you call the function. Suppose an escrow agreement is funding complete and a new one has begun on the property ID. In that case, your first contributions token share will automatically get withdrawn while you are making a second contribution. You are calling this function automatically before including your contribution to the new agreement.

function withdrawAVECFromEscrow(

          bytes32 _PropertyID) 

Auditing Escrow Agreements

Step 1(User).

Using this function, you can pull in all of the live information available on an escrow agreement. To return the data to your UI, Enter the property ID for that property’s current escrow agreement info card.

  1. bytes 32 Property ID is the property ID of the escrow agreement getting viewed.
  2. address recipient Of Funds is the address of the recipient of funds for the escrow agreement getting considered.
  3. bytes 32 recipients Name the bytes 32 encoded name of the recipient for the escrow agreement getting viewed.
  4. uint 8 escrow Agreement Number is the number of the current escrow agreement on the property I D.
  5. bool escrow Completed is the true-false value that indicates whether the escrow agreement is funding complete or not.
  6. uint 256 milestone Price Of Escrow In E T H is the amount of ethereum represented in a milestone achievement value that, when matched by contributions, allows the CEVA to mark this escrow agreement as funding complete = true.
  7. uint 256 tokens Available Total is the number of single tokens available to purchase for the agreement’s total milestone ethereum price.
  8. uint 256 tokens Available Current is the number of tokens currently escrowed for purchase from the property. You can calculate the amount of ethereum you would like to contribute by deciding how many tokens you want and multiplying that by the number of the tenth item in this list E T H per Token. Which will give you the amount needed to reserve that many tokens represent in Wei. Sending that amount of value with the “contribute to property escrow agreement” function will accumulate to your address the tokens if they are currently available.
  9. uint 256 total E T H Received is the total amount of Ether that has gotten contributed to the escrow agreement so far.
  10. uint 256 e t h Per Token is the amount of Ether represented as Wei. You need to contribute this amount per 1 token received from this escrow agreement to accumulate them in your wallet before completing the escrow. The minimum contribution a user can make has to equate to the e t h per Token value in this agreement; the maximum is the difference between the milestone price in Ether plus one E T H per tokens value and the total E T H received.
  11. uint 256 property increase is the amount of an increase this escrow agreement will contribute as an adjustment to the property value once it has gotten funded. When the escrow agreement is funding complete, inflation will occur for token owners on their next update rolling property value member function called before most workflows run through their main procedures. Keeping wallet balances consistent before transferring value, equity rents shares, etc.
  12. uint 256 Agreement Amount Due In Tokens is the amount due in tokens when escrow agreement is funding complete awarded to the individual wallet currently viewing the get escrow card.

agetEscrow(

          bytes32 _PropertyID)

Controlling AVEC, ONUS, and OMNI(6).

Step 1(Member)

Once you have received some AVEC or ONUS into your wallet, if you are a user with a wallet with a privilege level one (member), you can convert AVEC into ONUS and ONUS into AVEC using this function. To make your conversion, enter 1 in the one AVEC two ONUS field, i.e., one if you want to convert AVEC into ONUS two if you want to convert ONUS into AVEC. In the uint 256 tokens field, enter the number of tokens you would like to convert. Then in the property ID, enter the property ID of the property from which you are converting tokens. By doing this and calling the function, you automatically see a conversion of your balance equal to what it was just prior—converted. On the AVEC property ID’s balance if you chose to enter two into the first field or on your wallet’s ONUS balance if you entered one. 

amemberConvert(

          uint8 oneAVECtwoONUS, 

          uint256 tokens, 

          bytes32 _PropertyID)

Step 2(User)

Managing the inflation and deflation of real estate assets can get challenging to manage. Balancing the values when you involve multiple owners and ledgers can get even more complicated when you try to scale it. Solving this issue is easy with the Ethereum virtual machine and the proper logic. First, the user has a variable that stores the last known property value of any given property they may have interacted with through minting or transfers. Second, the property has a variable that stores its current value, and third, ceva has the user privilege level and authority to approve property value adjustments. When these adjustments get approved through the “adjust property value” function of the smart contract, two functions manage the update of the rolling property value for each property and the global portfolio at the same time. These functions balance the token ledgers of a local property’s proportional ownership for each user address(AVEC) and the global properties’ balanced ownership amounts for each user address(ONUS). Between users and property, these values are all updated automatically before functions that change the state of the contract can get called; this happens before transfers, property values adjustment, and any other internal operation that maintains the state of the contracts portfolio value. AVEC tokens represent all of the 100$ portions existing within a property’s entire value, including the underdeveloped and profitable value along with any senior liens or debts. When AVEC gets digitized with a digitization bundle agreement on a qualified Exist Crypto Platform through a KYC verified Member Account and is escrowed with its debt, purchase, and or development costs included in the total amount of tokens. Minting takes place, and the number of tokens that CEVA didn’t escrow for options, fees, liens, debt, or development distribute to the owner, while the tokens escrowed get distributed to many new owners.

Each new owner has their token ledger for either that property (AVEC) or the global portfolio(ONUS) if they are a member AVEC if they are a guest ONUS. Each property’s AVEC token balance ledger has its unique property ID the contract uses to reference that value. For ONUS, on the other hand, all token balance ledgers share the same property ID; this ID is the default that gets set when you are formed as a user or after every transfer. The ONUS property value does not get decided by minting (even though the minting fees contribute a small portion of its value). It gets determined by the amount of AVEC converted into ONUS at any given time. Every property has a live balance showing the amount of avec that has gotten converted into ONUS out of its total AVEC Minting amount. This balance lets you know how much AVEC is available on that specific property.

Suppose you want to convert your ONUS into that property’s AVEC; by knowing the amount of AVEC available, you can convert accordingly without causing the function to fail by overcontributing an amount more significant than what is available. It also contributes to the ONUS global portfolio value. The properties global balance of ONUS inflates and deflates along with owner token ledgers; the difference between ONUS and AVEC and how they distribute their gains and losses are few. The first difference is when a property’s ONUS contribution grows or falls in amount through a value adjustment to the property. The profits and losses get split between all ONUS token holders. They are causing a less significant impact on token holders. The effect of the gain or loss on balance ledgers is split evenly amongst all ONUS token holders by adding to or subtracting from the total value of the global properties. The total value of the global properties referenced by the properties ID determines the amount of ONUS in each ONUS token holder’s wallet when the update rolling property value member function gets called. Before any state changing operation can update the ledgers and necessary balance checks and calculations occur during transfers of value, equity rent envelope shareholders, and escrows, the update rolling property value member function always gets invoked within the process. In the case of AVEC, when a property value adjustment takes place, the AVEC token holders would split the gains and losses between themselves automatically when the update rolling property value member function is auto invoked by state-changing processes. Your AVEC and ONUS token balances will reflect the increase or decrease of their total property values. Whenever an adjustment gets made, the amount reflected will match your ownership percentage out of that property’s live value, globally for ONUS and locally for AVEC. The adjustments to those values won’t get made except when calling state-changing functions; Equitable Builds Inc created a public function to update that value manually. Entering the holder address you are trying to update and the unique property ID for the property you intend to update, then calling the function updates the balance ledger for accurate viewing. Otherwise, viewing the ledger of an account that hasn’t received a recent internal update, the results may show inaccurate details if a property value has gotten adjusted recently. This will happen less frequently for avec and more frequently for ONUS, considering the total value gets adjusted every time a contributing property’s value is modified. Transfer and other state-changing functions will work as planned with accurate balances. The update rolling property value member function gets called in priority for any function in this category. To review if you have a balance of AVEC on that property and its value doubles since you’ve last updated, the amount of AVEC in your ledger will double when it updates. The same applies in reverse in the case of a loss. If you have a balance of ONUS and the total property value doubles since it was last updated, the ONUS amount in your ledger will double when it updates. The same applies in reverse in the case of a loss. For example, if the ONUS property value falls by 50% through value adjustments to the many global properties when your balance ledger gets updated, it will fall in amount by 50%.

amemberUpdateRollingPropertyValue(

          address _holderAddress, 

          bytes32 _propertyUniqueId)

Step 3(Member).

Wallets with a user privilege level can withdraw from one of the thirteen available envelopes described in the white paper. These envelopes split the fees as described and accrue them at a total all-time received amount of fees. The total withdrawal from the envelopes gets deducted from the all-time received amount; the difference is what’s available to withdraw. Based on your ownership percentage of the total amount of share holds in each envelope, you are entitled to withdraw from what is available. Your wallet has a balance that keeps track of the available portion of all time fees due to you, and deducted from it is another balance that shows your total withdrawals; the difference is what you receive when you call this function. When equity rents share-holds get transferred from one user to another, they carry these values with them to the recipient and assign them to that wallet. When an amount of tokens gets minted for each 100$ Token, one equity rent share-hold gets created for each of the thirteen equity rent envelopes contributing to the total in existence. The total amount of fees ever received is divided by the total number of equity rents created across the board, defining the sum a single share-hold is entitled to withdraw. The total withdrawn by all users gets divided the same way then is deducted from the total one share-hold is entitled to withdraw. Resulting in the total available that one share-hold can withdraw. When calling this function, the total available is always withdrawn in a lump sum and added to that share-holds balance of total withdrawn fees.

Along with this, the value gets attached to the wallet that withdrew it, preventing a double withdrawal on ownership change due to all-time calculations. When share-holds get transferred, these amounts are carried with them to the new owner and deducted from the old one. When tokens get minted and share-holds get created, the fees will automatically begin to accrue due to those share-holds and their owners. When you originally mint your tokens, the share-holds will not be entitled to withdraw their equity rents until the wallet that received the minting value of the AVEC circulates the tokens that created them. Doing this encourages big players to distribute tokens and generate equity rents without offsetting their overwhelming share of the totals number of holds available. It also discourages users from transferring and selling equity rents share-holds that haven’t created any circulation because they cannot withdraw from the envelopes. Doing this stimulates the economic unit and rewards home-owners for digitizing properties. Providing income, a maintenance budget, supplementing taxes, and many other benefits that usually get offered to members of an H O A. With use-based fees, the association can maintain a more balanced budget for the entire portfolio, the properties, and the home-owners. It gets done without drawing from time-based fee modeling. It provides a win-win performance-based operation model that can scale to entire associations while still decentralizing itself, making it easily adaptable for any new or old, developed, or undeveloped environment.

amemberWithdrawDividends(

          uint8 _envelopeNumber)

Step 4(Member).

When making a transfer or calling most other functions that involve exchanging your property’s AVEC token value, it is essential to set your transferring property ID. When meeting the erc20 token standard while simultaneously controlling the values of fungible(ONUS) and semi-fungible(AVEC) tokens, the smart contract uses this function to switch token balance ledgers using a property id and a numbered transfer type. To transfer AVEC, enter a property ID and a token type of 1. Doing this and calling the function will allow the transfer function to draw value from that property’s AVEC token balance ledger. Once the single AVEC transfer is complete, the smart contract will reset the transferring property ID to the ONUS property ID for the wallet that gets called the transfer function. Suppose you have switched from the ONUS property ID to the AVEC property ID, and you would like to switch back without making a transfer. To do this, enter your property ID and then a token type of 2; this will reset your transferring property ID to the ONUS property ID; otherwise, making a transfer will also cause this to happen. To transfer ONUS, enter any unique property ID and enter a token type of 2 and call this function.

function aaswapType(

          bytes32 _propertyUniqueID, 

          uint8 _tokenType)

Step 5(Member).

Suppose that you would like to liquidate the future value of your equity rents by selling the share-holds. To do this, you need to use this function, enter the number of share-holds you would like to exchange to another wallet, and the holds will exchange automatically and start accruing fees for the new owner. When you use this function to transfer share-holds for an envelope from one wallet to another, the share-holds will carry the values that keep track of the token circulation from the original minting tokens. These share-holds will not generate equity rents unless they have gotten attached to a wallet that circulates the amount required to unlock the fees accrued so far.

aSellFeeSharehold(

          address _toAddress, 

          uint256 _amount, 

          uint8 _envelopeNumber)

Subsection(ERC20 Functions)

The following standard allows for the implementation of a standard API for tokens within smart contracts. The ERC20 token standard provides basic functionality to transfer tokens and will enable tokens to be approved so another on-chain third party can spend them.

NOTES:

  • The following specifications use syntax from Solidity 0.4.17 (or above)
  • Callers MUST handle false returns (bool success). Callers MUST NOT assume that false never gets returned!

Step 6(User).

approve

Allows _spender to withdraw from your account multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value.

NOTE: To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender. THOUGH The contract itself shouldn’t enforce it, to allow backwards compatibility with contracts deployed before

function approve(address _spender, uint256 _value) public returns (bool success)

Suppose you would like to give control of the spend value of your wallets AVEC or ONUS tokens; in this case, you would enter the address of the spender and the number value of their allowance then calling the function. When doing this, you allow that wallet to spend that amount of tokens out of your wallet’s currently selected transferring property ID. Because this transferring property ID automatically resets to the ONUS property ID on transfer calls, a pre imminent second approval gets required for AVEC. Using the A A swap type function will cause this approval to happen before the allowance recipient tries to draw from your property’s specific avec balance. Otherwise, this function will be drawing from the ONUS Property ID on concurrent transfers. To grant an allowance to another wallet, enter the spender address and the value that you would like to allow them to spend from your wallet.

approve(

          address spender, 

          uint256 value)

Step 7(User).

transferFrom

Transfers _value amount of tokens from address _from to address _to, and MUST fire the Transfer event.

The transferFrom method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. The function SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism.

Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.

function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)

Suppose another user has given you an allowance out of their wallet using the approve function. With this function, you get to spend the balance of that allowance. When trying to transfer the out of another user’s property in AVEC pre imminently the address getting used for the allowance must call the “A A swap type” function to set their transferring property ID to the property from which you are trying to draw value. Otherwise, the “transfer from” function will pull the value from the default property ID, the ONUS property ID. To spend an allowance, enter the address of the wallet in “address from,” the address to send tokens in “address to,” and the amount in “U int 256 tokens.” Then call the function; doing this will deduct the number of tokens from your allowance and the property id token balance ledger of the “from” wallet address and attribute it to the recipient entered into the “to” address. Suppose you call this function because you have an allowance granted by another wallet, and they do not have the tokens to cover your transfer of the allowance; the function will fail, resulting in no transfer of tokens. Guests can transfer ONUS while members can transfer OMNI.

transferFrom(

          address from, 

          address to, 

          uint256 tokens)

Step 8(User).

transfer

Transfers _value amount of tokens to address _to, and MUST fire the Transfer event. The function SHOULD throw if the message caller’s account balance does not have enough tokens to spend.

Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.

function transfer(address _to, uint256 _value) public returns (bool success)

Suppose you have a balance of tokens in AVEC or ONUS and would like to transfer that value from one wallet to another. In that case, you would enter the recipient’s address into the “address to Address” field and the number of tokens into the “U int 256 amount Of Tokens” field, then call the function. By doing this, you will transfer the number of tokens you input out of your wallets currently set transferring property ID the ONUS property ID by default. Suppose you would like to use the AVEC token balance available to your wallet from a specific property. Use the “A A swap type” function to change your property ID to the property ID you would like to pull value out of, and then use this function(Available to members only). Using this function, you can increase the number of tokens circulated by your address to entitle yourself to more of your accrued equity rents if you have any. Guests can transfer ONUS members can transfer AVEC.

transfer(

          address _toAddress, 

          uint256 _amountOfTokens)

Becoming a Founder Developer(7)

Step 1(Member).

Once you have completed the onboarding process for members on the website after receiving an invitation from a founder developer and you have had your WHOA structure set by that founder developer. Using a balance of at least 1000 tokens, you can call this function to deduct the value from your wallet. Doing this distributes the commission to your senior WHOA structure CEVA, Founder Developer One, and Founder Developer Two completing this dispersion automatically. The rest of the license fee gets dispersed to the set fee wallet for the WHOA set by the smart contract fee wallet secret.

amemberBuyFounderDeveloperLicense()

Key:

bytes32

ONUS Property ID bytes32 = 0x676c6f62616c0000000000000000000000000000000000000000000000000000

Bytes32 is exactly 32 bytes long. It takes exactly one 32-byte word to represent a bytes32 because there’s no need to set any space aside to encode the length. The length is always 32. A bytes with 32 bytes of data needs additional encoding to deal with variable length.

An important practical difference is that the fixed length bytes32 can be used in function arguments to pass data in or return data out of the contract. The variable length bytes type can be a function argument also, but only for internal use (inside the same contract) because the interface, called the ABI, doesn’t support variable length types.

bytes32 can get created with a function in this smart contract by entering the string you want to encrypt into a bytes32 value and calling the function.

function agetstringToBytes32(string memory source)
pure
public
returns (bytes32 result) {
bytes memory tempEmptyStringTest = bytes(source);
if (tempEmptyStringTest.length == 0) {
return 0x0;
}
assembly {
result := mload(add(source, 32))
}
}

bytes32 can get decrypted using a function in this smart contract by entering the bytes32 value into the function and calling it.

function agetstringToBytes32(string memory source)
pure
public
returns (bytes32 result) {
bytes memory tempEmptyStringTest = bytes(source);
if (tempEmptyStringTest.length == 0) {
return 0x0;
}
assembly {
result := mload(add(source, 32))
}
}

using these function you can read and write the values required to interact with the smart contract that are usually a little more difficult to work with.

address

Example: 0xc58643f1BE059dfD05147C6b3D12AA1E59F983d8

The address Solidity value type has two similar kinds: address holds a 20-byte value (size of an Ethereum address). address payable is the same as address, but have transfer and send members. Making it possible to transfer ethereum with calls to the smart contract.

uint256

Example:3839388098980980809809898888888

For example if you store your number in the uint256 type, it means your number will be stored in a 256 bits unsigned number ranging from 0 to 2²⁵⁶. … In Solidity, shift right maps to division so the shifted negative values are going to be rounded towards zero (truncated).

uint8

example: 0 – 255

Unsigned Integers of 8 bits. A uint8 data type contains all whole numbers from 0 to 255. As with all unsigned numbers, the values must be non-negative. Uint8’s are mostly used in graphics (colors are always non-negative).

bool

example: true

example: false

 The bool data type can be used to represent scenarios that have binary results, such as true or false1 or 0, and so on. The valid values for this data type are true and false. It is to be noted that bools in Solidity cannot be converted to integers, as they can in other programming languages. It’s a value type and any assignment to other boolean variables creates a new copy. The default value for bool in Solidity is false.

Scroll to Top