EntityScript™ Digital Value System
A cerebral structure can be used to house endpoints to transfer digital stores of values that represent traditional currencies, point systems, and other crypto-based payment formulas.
This section is being edited*
Endpoint-based transactions
- The following containers are valid when performing digital-transfers
- blob General transaction data stored in unstructured or undefined I/O format as a blob
- cache Callable transaction records from Nth last transactions
- communications Local service communications logs
- entity-output formatted output logs for completed transactions
- entityscript-ore Retrieval-ready endpoint logs of process-ready assets by the IPDVC™
- fed-by Verification logs that are being pulled in from other verified access-points
- output-flush Logs that are ready to be flushed at the start of a new instance transfer
- output-slug Logs that are meant to process a constructed class data structure that's been verified by C.ORE™
- output-structure EntityScript™ compliant structures that is transaction ready
- output-vectorized-data Vector-ready compliant EntityScript™ structure that is able to be accelerated with a vector-processor
- server Server communication logs
- structure A log of an individual structure that can be used to feed in-transit data to another log
- system-lookup A system-verified record of a transaction being commited to the blockchain.
- system-routine Automation routines built for moving preset value systems from one location to another
- vcnkey: The output of a block-transaction with a blockchain (such as CORE.HOST™) containing valid ledger-data.
Exchange formats
- Value stores are made general through the following standardized exchange format rules
- These units have no defined value but adhere to a defined system of programmatic exchange
- The system has 5 properties
- ItemVisualIdentity
- UnitName
- ByRarity
- ConversionMap
- CoreUnitDescription
In testing, the following table was defined and is accessed within core_transmitter of the C.ORE™ framework. This transmitter includes server-time based standardized unit values that can be distributioned to connected member hosts and defined conversions of each unit are built and enforced with EntityScript™.
| IdentityItemVisual | UnitName | ByRarity | ConversionMap | CoreUnitDescription |
|---|---|---|---|---|
 |
DGOLD-X-Bronze | Common | 250,000 Distributed Daily, no base value - 1/40,000 a DGOLD-X | DGOLD-X-Bronze can be exchanged into the server each day to keep your network ad-free, permanently. You get Bronze each morning at 00.01 server time. If you don't exchange it or only exchange part of it to peers, the machine reclaims what's left at the end of every day and the DGOLD-X-Bronze goes into a collective server-holding account. When there is 400,000,000 DGOLD-X-Bronze there, it forks over the span of 24 hours known as 'THE AUDIT PERIOD' and at the end, 1 Diamond C.ORE™ is created and made available to the community according to a giveaway-game format. 1 Silver is worth 20,000 DGOLD-X-bronze. |
 |
DGOLD-X-Silver | Uncommon, achieved | 1/2 of a DGOLD-X | DGOLD-X-Silver units are used to aggregate tasks into value groups, and reward completed actions of various types. They're allotted once per day, 20,000 to be exact. They're only able to be spent on unlocking certain additional meta-structures within the program. |
| VIRTUAL | VirtualFigment™ | Special Object (Periodic) | AWARDED FOR COMPLETING THE TUTORIAL - grants 1 VirtualFigment™ struct-entity that can be used for publishing content to peers. | You have to earn the right to post by completing and continuing to understand a community guidelines rule-set. |
 |
DGOLD-X | Rare: Upgraded to -> 'HIGH EXCHANGE' type | Earned through various defined behavior | This is the basic system-crypt-peg within C.ORE™. All other units operate based off of it. |
 |
Diamond C.ORE™ | MINTED: VERY RARE | Prestige | When the CommunityCollection reaches 400,000,000 bronze, 1 Diamond C.ORE™ is created and made available to the community. A Diamond C.ORE™ can be used to unlock general chat structures and various long term meta-methods. No one can speak in general until they've discovered at least 1 Diamond C.ORE™. MAX 1 per day. Anyone who has discovered a Diamond CORE™ may also give away an established set of chat invitations monthly afterwards to peers. |
 |
Gem C.ORE™ | GEM | Special Object: Awarded | Gems are awarded to you for community building and assistance. They're based on internal nominations. They hold no value, but are required to be above rank 30 in the system. Above rank 30 provides additional meta-structures. |
 |
Mystery C.ORE™ | Unseen | Estimated Exchange: 4,000 DGOLD-X | Somewhere around the year 2020, a machine known as C.ORE™ came online and began indexing information according to rarity and potential digital value. The mystery core containes various meta-structuring properties granted by this type, such as gifting, one-way transactions, and other non-standard transfers. |
When any resource is made available to exchange types, it's also recorded on three sub-tables. Here is an example of what each of the 3 sub-tables look like.
1.) Value-table, general:
| Domains | C.ORE™ | Gold | Silver | Bronze | Diamond | Gem | Mystery |
|---|---|---|---|---|---|---|---|
| 3 | 3 | 3 | 3000 | 30000 | 1 | 3 | 2 |
2.) Public Domains accepting ORE™ a simple table used to keep track of server-resources that are excepting a structured digital currency.
| domain | times seen |
|---|---|
| https://www.ryanmckenna.com | 2 |
| https://www.NewEntityOperations.com | 23 |
3.) Private Domains accepting ORE™: a simple table used to keep track of server-resources that are able to be unmasked with a valid key that accept structured digital currency.
Together, these silos create a compliant digital value exchange system that can be processed by C.ORE™ utilzing a website like CORE.HOST™. 'ORE' is the default exchange base-value, although it is valueless as a currency. ORE holds value as a store of activity-based time-value only and it stands for Operations Resource Enclave™.
Because EntityScript™ can process ORE™ through defined scoping, you have a exchange-based meta-format that can accept any store of value by default.
The following set of publishing tools make up the entirety of this posting, editing, access-control, and data-removal system.
Block device ledger: Standard .entity retrieval mechanism from an ordered and compliant index
| position | index-slug | vcnkey | ore-access | master-copy | record-location |
|---|---|---|---|---|---|
| 1 | LINKED_OBJECT_1 | KHN3LPHN57H89L | 1 DGOLD-X-Bronze ORE | KHN3LPHN57H89L/DS3927107.entity | RECORD |
| N* | LINKED_OBJECT_N | ULPH73L9BYNB3R | 1 DGOLD-X-Bronze ORE | ULPH73L9BYNB3R/DS7204432.entity | RECORD |
'index-slug' is setup to also take keys. Keys are created by others in C.ORE™ or adhere to a prebuilt kind. For instance, 'L:' at the beginning of index-slug declares a readable and compliant list location.
'index-slug' can also be either openly named, or masked through a special property called 'MASKED ENTITY'. When a masked-entity is created the default master-copy location is 'MASKED RECORD', while the default 'record-location' value will be set to 'UNAVAILABLE RECORD'.
Each of these hidden record types aren't set up to follow any specific position in this example, but a position does exist. While an access-point is live, three distinct locations become available once activated. The first is a 'index-slug' location, storing the resource location of the LINKED_OBJECT. The second linked-to position is the 'master-copy'. A master-copy is a direct link to the stored location on a compliant block-exchange structure. Lastly, the 'record-location' provides a unified resource point that stores meta-data about the linked-entity.
Together, these actions store the meta-information on a ledger and become an available resource that can evolve without human input.
FinalLedger
| position | index-slug | vcnkey | ore | master-copy | record-location |
|---|---|---|---|---|---|
| 1 | data_sheet_b | NK3hPHNsLpHHHa | 1 DGOLD-X-Bronze ORE | NK3hPHNsLpHHHa/DS3927107.entity | RECORD |
| 2 | threed_Entity_unique | yNXLPHa390HanP | - | yNXLPHa390HanP/DS7964744.entity | RECORD |
| 3 | MASKED ENTITY | AHnsLPyaH3a9PN | - | MASKED RECORD | RECORD UNAVAILABLE |
| 4 | MASKED ENTITY | BLPa2HnnLP210N | - | MASKED RECORD | RECORD UNAVAILABLE |
| 5 | L:OriginalUSPresidents | iPhs29Lna21qfp | - | iPhs29Lna21qfp/DS1000022.entity | RECORD |
With these ledger types now available, records can be determined 'ONLINE' or 'OFF' making them either discoverable to those with resource access or they will not be available if they're 'OFF'. Next, the default record values of each entry will generate into a posted and compliant block-storage structure according to this format. Here is a look at the default record-store.
Example:
C.ORE™ Record - DS3927107
| Creator | affiliated-tag | time-stamp | master-copy | Entity | vcnkey | type | ore | extension |
|---|---|---|---|---|---|---|---|---|
| Ryan McKenna | RyanMcKenna | 08/23/2020 - 06:34:55.3332 PST | NK3hPHNsLpHHHa/{}/DS/3927107.entity | data_sheet_b | NK3hPHNsLpHHHa | struct-entity | 1 Bronze ORE | .ds |
FinalIndex: General mass-access location
A final index is now made available. Here is an entire FinalIndex example.
C.ORE™ - FinalIndex
| Entity | type | index-slug | vcnkey | level | ore | extension | status |
|---|---|---|---|---|---|---|---|
| Actor List | struct-entity | data_sheet_b | NK3hPHNsLpHHHa | protected | 1 DGOLD-X-Bronze ORE | .ds | ONLINE |
| Basic Square | 3D ASSET | threed_Entity_unique | yNXLPHa390HanP | open | - | .entity3d | expired |
| MASKED | PRIVATE | AHnsLPyaH3a9PN | open | 42 DGOLD-X-Silver ORE | . | ONLINE | |
| MASKED | PRIVATE | BLPa2HnnLP210N | open | 2 DGOLD-X-Silver ORE | . | ONLINE | |
| US Presidents | struct-entity | L:OriginalUSPresidents | iPhs29Lna21qfp | compiled | 1 DGOLD-X-Bronze ORE | .ds | ONLINE |
System Audits for transactions
Audit Tags
System Audits can be as simple or custom as you need. They can replace the need for traditional introspection tools if designed into your extensions properly.
A Use this tag when logging a generic audit block
E Use this tag when logging an `event` block as described in the standard EntityScript™ library
S Use this tag when logging a `search` block
P Use this tag when logging and identifying a parsed behavior
K Use this tag when logging and identifying a new `main` or `active` function call
System Audits: Extended file auto-checks
The main .CORE/ directory performs very little. It does however perform audit_home checks. Essentially, it looks for a status queue. If the queue exists the system starts and stays running. If it doesn't exist it can start but won't run.
.audit_home/STATUS.X will tell the operator and the machine upon startup that the system and all tracked/known files from the last session are still there and in working order. The goal is to take anything that makes this hit to '.ERROR' and to isolate it for later processing.
This folder will produce the following file if everything is okay:
produce in-> .CORE/
.audit_home/STATUS.OKAY
If there was a syncing error or startup problem, the following will be true.
.CORE/
.audit_home/STATUS.ERROR