Smart Contract operations on tokens

One of the ways an owner of tokens can perform operations on them, is by using smart contracts referencing the tokens. The operations that can be used are defined by the https://paiwise.tagroot.io/Schema/NeuroFeatures.xsd namespace, the same namespace used to create the tokens.

The operations supported include:

• Create
• Destroy
• Donate (new)
• Transfer

Create

A smart contract with the Create machine-readable element creates one or more Neuro-Feature tokens. Creating tokens may require a comission fee to be paid first, as defined by the smart contract template used. An initial value is set by the creator.

Destroy

Destroy on the other hand, in a smart contract, destroys the token, if such is permitted by the token definition. During the creation of the token, the creator defines under what cirumstances the tokenⓈ can be destroyed, and by whom (if at all):

• CreatorCanDestroy defines if the creator is allowed to destroy the token.
• OwnerCanDestroyBatch specifies that an owner can destroy a token or tokens, but only if the owner is the owner of all tokens created using the same creation contract (here called a batch of tokens).
• OwnerCanDestroyIndividual allows the owner to be able to destroy any token it owns, regardless if other owners owns tokens from the same batch.
• CertifierCanDestroy can be used to give privileges to a certifier signing the token creation contract, to destroy any of the certified tokens. This gives the certifier the authority to ensure and enforce the rules set forth in the creation contract.

Donate

The Donate operation is new as of build 2025-01-30. It allows an owner to donate a token or set of tokens to another, without a monetary recompensation. This operation does not change the registered last value of the token. (This is the initial value set during creation if the token has never been transferred, i.e. sold.) The donation operation registers a specific donation event for transparency, showing the ownership has changed without compensation.

Transfer

The original way to change ownership of a token is called Transfer and includes a payment of eDaler® to compensate for the transfer. This payment may include a commission to the Trust Provider hosting the token. The payment will also be recorded as the new value of the token, and a corresponding event will be recorded, for transparency, giving future new owners (buyers) a way to transparently review a token’s history and trade.

LegalLab

The LegalLab repository contains multiple examples of token operations. This includes examples of the Create, Destroy, Donate and Transfer operations.

#api, #neuron, #neuro-feature, #contracts, #legallab, #new

Data Sheets in Digital Sensor Twins

The LegalLab repository contains an example smart contract for creating digital sensor twins. This template, together with the LegalLab utility, has been updated to support uploading and presentation of data sheets for the underlying sensors being mirrored digitally.

The process of attaching such data sheets is straight-forward:

• Publish the new digital sensor template to your Neuron®, and get it approved.

• Create a smart contract based on this template, pointing to the sensor you want to mirror.

• Before signing the contract, upload any number of data-sheets appropriate for the digital twin. If these attachments are in the following formats, they will be presented together with sensor data from the sensor:

  • Plain text file (*.txt)
  • Markdown text file (*.md)
  • Image files (*.jpg, *.png, *.webp, and other supported formats)
  • Microsoft Word files, in the interoperable OpenXML format (*.docx)
  • Microsoft Excel files, in the interoperable OpenXML format (*.xlsx)
• Once data sheets have been uploaded, sign the contract accordingly.
• Once the token has been created, create a Present Report to view sensor data, together with associated data sheets.

Note: For performance reasons, it might be less resource-intensive and quicker to pre-convert MS Word files to Markdown, and upload the Markdown file.

Note 2: For security reasons, only files (actually Internet Content-Types) recognized by both LegalLab and the Neuron® will be accepted.

Note 3: To be able to upload and process Microsoft Word documents and Excel spreadsheets, you need to install the Microsoft Interoperability package. You can also check microsoft for more information related to Microsoft interoperability.

#new, #features, #contracts, #legallab, #sensor, #iot

Contract Attachments in LegalLab

While the TAG Neuron® and the underlying infrastructure has supported attachments on legal identities and smart contracts for a long time, LegalLab has not enjoyed this support, until now.

The process is simple: After having created a smart contract, from a template, but before signing it, it is possible to upload signed attachments to the contract. Attachments can be of any type that is recognized by the embedded content architecture of both LegalLab, and the TAG Neuron® to which it is connected. Each uploaded attachment is signed by the uploader, and the signature is stored with the contract. When anyone signs the contract, the references to uploaded attachments is included in the signature, which is the reason that new attachments cannot be uploaded once the contract has received a client signature.

You can find the area where you manage contract attachments above the list of client signatures. After creating a contract, while it is Approved, but not yet with signatures, this area would look as follows:

Press the Upload button to upload relevant files. A record of each upload will be displayed, after all validation checks have been performed:

To double-check the contents of an attachment, you can always download it by pressing the corresponding Download button. You can also remove an attachment by pressing its Remove button. Once you start signing the contract, attachment buttons that modify the contract will be disabled:

#new, #features, #contracts, #legallab

New features in human-readable text section of smart contracts

When creating smart contracts in the federated Neuron® network, you have to specify both machine-readable and human-readable sections. The human-readable section has had limited formatting capabilities, for portability reasons, compared to richer formats such as HTML, Markdown, or word-processors, such as Microsoft Word (more on how to use MS Word to create smart contracts later). This set of formatting capabilities has been extended to make it easier to represent texts that are commonly written in such other formats. The following text outlines what has been added in this new version (from build 2023-10-09 of the TAG Neuron®:

List items with block contents

In the previous version, only inline-content was possible in list items (i.e. items in ordered or unordered lists). Inline content included text and basic text-formatting operations (such as bold, italics, underline, etc.). But you could not create more advanced list items, such as items containing multiple paragraphs, or nested lists. It is now possible to create the following types of lists:

• Lists can now include items constructed using multiple paragraphs

  (This is a second paragraph of the first item.)

• Lists can also contain nested lists. This makes it possible to create multi-level lists.

  1. This is the first item of a nested list.
  2. This is the second item.

Line-breaks

Inline text can now include line-breaks. This makes it possible to present property values in the following way (as an example):

Property:
Value

Images

It is now possible to include images in the human-readable text. You can either include an image inline, in flowing text, or standalone, as a separate object in a separate paragraph. Such standalone images can have a figure caption. Typical uses for images may be to include logotypes, graphs, charts, diagrams or similar graphical components into the body of the contract.

Security Note: To avoid security issues, where clients and servers are triggered to download contents via URLs, URLs are not allowed in smart contracts. This means that all images inserted into a smart contract, are encoded directly, by inserting the binary image directly as BASE64-encoded content. This also makes sure the image in the contract is immutable, and cannot be changed by external sources. It also makes sure viewers of the image are not tracked, by logging who accesses a given URL. This encoding of the image is typically done via conversion from an intermediate format, such as constructing a contract from Markdown. The Markdown-processor converts the image to BASE64-encoded image that is inserted into the contract.

Tables

Tables can now be encoded into human-readable sections of smart contracts. Tables consists of rows, each row consists of cells. Cells can either be normal cells, or header cells. Cells can also span multiple columns.

Portability Note: Tables may lend users to create wide content, i.e. content that much extend horizontally to be readable. This may become a problem when rendering the contract in portable settings, where the contract should be viewable by devices that have small screens, typically in portrait mode (like phones). Care should therefore be taken when using tables in smart contracts, to avoid tables that require wide screens to be properly readable.

Nugets

Nugets related to smart contracts have been updated. So has TAG repositories working with smart contracts. Make sure to get latest version, or upgrade nugets, to use these latest capabilities.

#new, #features, #contracts

Using Microsoft Word to create smart contracts

This article is being written…

#new, #features, #contracts, #word, #microsoft, #neuro-foundry