RFC - Remove Transaction Managers

The new RFC process is off to a bright start with the Remove Transaction Managers proposal by who else, but @dirvine …looks to be another evolutionary leap for SAFE.


Have network only recognise two primary data types, Immutable and Structured.

These types will have tag_ids to allow them to contain several data types that can be used in the network by users of the client interface. This does mean a change to default behaviour and is, therefore a significant change.

ImmutableData has already two sub-types (Backup and Sacrificial).

This proposal should simplify the sentinel and interfaces from routing to users of routing as there will be no need to pass down type information (i.e. how to get the name or owner etc.). These types can actually be defined in the routing library, allowing users of the library to use the type_tag to create their own types and actions on those types.



The primary goal is two fold, reduce network traffic (by removing an indirection, of looking up a value and using that as a key to lookup next) and also to remove complexity (thereby increasing security).

Another facet of this proposal is extendability.

In networks such as SAFE for instance, client app developers can define their own types (say of the fix protocol for financial transactions) and instanciate this type on the network. For users creating their own network they may whitelist or blacklist types and type_id’s as they wish, but the possibility would exist for network builders (of new networks) to allow extensibility of types.

What cases does it support?

This change supports all use of non immutable data (structured data). This covers all non content only data on the network and how it is handled:

(1) Data storage and retrieval

ImmutableData is fixed self validating non mutable chunks. These require StructuredData types to manipulate information.

These structured Data types may then create a global application acting on a key value store with very high degrees of availablity and security (i.e. create network scale apps)

Such apps could easily include medical condition analysis linked with genomic and proteomic sequencing to advance health based knowledge on a global scale. This proposal allows such systems to certainly be prototyped and tested with a high degree of flexibility.

(2) New protocols

As these data types are now self validating and may contain different information, such as new protocols, rdf/owl data types, the limit of new data types and ability to link such data is extremely scalable. Such protocols could indeed easily encompass token based systems (a form of ‘crypto-currency’), linked data, natural language learning databases, pre-compilation units, distributed version control systems (git like) etc.

(3) Compute

Such a scheme would allow global computation types, possibly a Domain Specific Language (DSL) would define operator types to allow combination of functions. These could be made monotonic and allow out of order processing of programs (disorderly programming) which in itself presents an area that may prove to be well aligned with decentralised ‘intelligence’ efforts.

Linked with ‘zk-snarks’ to alleviate any ‘halting problem’ type issues then a global turing complete programming environment that optionally acts on semantic (‘owl’ / ‘json-ld’ etc.) data is a possible.

Expected outcome

It is expected removing Transaction Managers from network will reduce complexity, code and increase security on the network, whilst allowing a greater degree of flexibility.

These types now allow the users of this network to create their own data types and structures to be securely managed. This is hoped to allow many new types of application to exist.


Good catch. This project just makes sense and it’s crazy that most people of the world don’t see this coming.


This looks very promising, the ability to create our own transactable tokens is huge.

So SafeCoin will simply become a sub-type of the StructuredData type. But it still needs to be handled differently by the network than other sub-types right, or else people could simply upload new SafeCoins? Also, the transaction managers are currently reponsible for creating a (temporary) receipt (proof of transaction). How does that look with the transaction managers gone?

I’m not so worried about the extra refresh load, my guess is that the vast majority of new token types will barely have any data in them and won’t come close to that 100 KB.

I noticed the question mark behind the 4 byte data size of the tag_type. I feel 8 bytes would be a safe choice, unique transactable tokens have practically infinite use cases so I could see a range of 2^32 filling up over the years.


…and the actual discussion around the RFC is interesting…it serves as a sticky way of presenting solid ideas…instead of them being lost inside a forum or chat room.

So ideas can get thrown around here and if some kind of positive consensus is reached, then a proposal could get forwarded as an RFC for consideration.

The project must be going ok, as I haven’t seen any big proposals to change the core recently :smile:


Thanks for the link, I’m too busy lately to keep track of it all, that discussion answers some of my questions.

1 Like

As long as the overall theory of operation of SafeNet still holds, then by all means. The K.I.S.S. principle applies.