Additional Features

Non-fungible tokens (NFTs) build logically on Geeq’s secure validation of transactions with application payloads and metadata. The issuer fixes the characteristics and terms of the NFT. An NFT is minted by sending an application layer transaction. When the mint transaction is validated, a permanent record is created in the application layer. No smart contracts are required.

Geeq NFTs are controlled by coin accounts, so transactions that involve existing NFTs interact only with the validation blockchain. The minting coin account is controlled by the introduction of a coin account subgroup called “proxy account”.

Additional Features

Geeq Data established Geeq’s software product development cycle. As a block of validated transactions is built, a block containing application transactions is built contemporaneously. However, Geeq Data did not require updates to an application ledger.

The addition of NFT and fungible token mints to the original roadmap puts Geeq’s technology to work to handle the full complement of blocks and ledgers: the validation blocks and ledgers used in the payments technology, the application blocks that record the application transactions, and the application ledgers that provide the current state of the application record.

Additional Features

At public mainnet, there will be three asset classes that a standard Geeq coin account will be able to control: $Geeqs, NFTs, and fungible tokens. Only the first was on the original roadmap, however, the Geeq team subsequently invented a method for secure atomic swaps without smart contracts.

After many inquiries about whether Geeq’s combination of security, low transaction costs, and ease of use could support other token types, we made the decision in mid-2022 to include NFTs and fungible tokens on the roadmap for public mainnet. Including support for these subgroups means the Geeq ecosystem will be able to expand in every dimension as the world moves toward tokenization.

Fungible token mints and transactions build on and extend the technology for NFTs and do not require smart contracts. When the mint is created, the total supply for that fungible token must be designated and cannot be changed. Geeq’s multi-chain architecture scales, so an unlimited number of mints and transactions can take place within Geeq’s own ecosystem.

Additional Features

A multi-signature account (MultiSig) is a type of proxy account. Proxy accounts were introduced earlier in the roadmap to control mints of NFTs and fungible tokens. A proxy account record is kept in the validation layer ledger after its creation. The creation of a multi-sig account and its use are ordinary transactions that do not use smart contracts.

While there is no Administrative User for a multi-sig, it is first created by a user who chooses both (i) a set of users authorized to endorse proposed transactions on the MultiSig account and (ii) the number of endorsements required to create a valid transaction. The set of Multi-Users is fixed after the account is created.

Additional Features

Certain types of Geeq proxy accounts are able to designate an Administrative User. Permissioning structures for accounts and applications are highly desired for enterprise use and mirrors the settings for most software applications with group accounts.

Traditional software users will find this approach to blockchain familiar. In addition, these features provide on-ramps to integrations with Geeq.

Validating transactions, writing blocks, and updating records when there are multi-user permissions is complex. At the application layer, Geeq’s protocols are even more detailed, in order to construct blockchains and update ledgers in the correct sequence.

However, Geeq’s innovations of (i) validating and settling every transaction on-chain, (ii) using templates that automatically separate the data payloads, and (iii) building validation and application blockchains concurrently, makes it possible to build multi-user permissions into Geeq’s infrastructure. In doing so, the doors to a new age for decentralized “coordination” have been thrown open for Geeqs to walk through.

Additional Features

The decentralized collaboration engine (DCE) is the last Geeq native generic application included in the roadmap before public mainnet. The DCE is the natural combination of previous development modules, such as multi-user permissions, application ledgers, Geeq Data, non-$Geeq tokens, block explorers with metadata, and micropayments.

The DCE provides accessible and secure attestations to versions submitted to systems that manage collaborative work. The need for this service will only grow: for on-location and remote work environments, as well as community-driven efforts that write to a common sources such as Google Docs or GitHub.

The DCE serves the purpose of removing central points of failure, releasing you from trusting other entities (such as Google Docs) to serve your documents or data accurately, because you and others will be able to verify its state for yourself. The DCE also preserves the option that non-permissioned parties will not be able to read the versions if users choose to store and exchange their versions without exposing their data to a non-permissioned party.