Update: SynthEstate and IBM HyperLedger Fabric

Annoucement

SynthEstate is currently being refactored to operate on the IBM HyperLedger Fabric blockchain.

What is IBM HyperLedger Fabric?

IBM HyperLedger is a modular blockchain framework that has become a standard for enterprise-grade blockchain projects due to its robust nature and performance at scale
Get more information about HyperLedger here

Why change blockchains?

To support an enhanced and responsive user experience, IBM HyperLedger is being used for SynthEstate for several reasons:
HyperLedger has proven its ability to scale and handle enterprise-grade transaction load in excess of 20,000 transactions per second (TPS)
HyperLedger's approach to consensus-based confirmation results in no transactions fees to the end user or platform operator, allowing SynthEstate to lower operating fees and provide more benefits to users
HyperLedger's security features have led it to being adopted by some of the world's largest institutional-grade blockchain projects, greatly reducing the risk of compromised security.

Update: beta-test results

End of beta-test period

The SynthEstate beta-testing period has now concluded. Thanks to all the testers involved. The purpose of the beta testing was to stress test the SynthEstate concept in real-world, daily use scenarios.

Feedback has been collected from both the beta testers, as well as running back-end analytics. A summary of this feedback is presented here, as well as next steps.

Key findings and feedback

Users consistently search by suburb first (98.6% first filter)
Selecting individual addresses averaged 3.2 per user
Users buy addresses in particular suburbs in bulk to gain exposure to that particular suburb’s growth potential
>90% of addresses were purchased in alphabetical order
Limiting purchase to 20/50/100 per order is a friction point
No AVM is able to provide 100% reliable, accurate coverage of individual addresse estimates
Suburb median/average/typical tokenisation
Missing addresses can created a consistently poor user experience
Displaying millions of points on a hosted, web-rendered interface is not possible without significant lag (>15 minutes per click/zoom/pan)
Unreliable and slow methods for tracking subdivisions was found
A pricing floor within 20% of current spot is a minimum threshold - -Consistent feedback about users taking advantage of “insider trading” on tokens they know will increase in value due to development, subdivisions, etc

Transition to release version

A suburb mean/average/typical price will be utilised for price setting
Guided and unguided suburb-first search will feature in the revamped UI/UX
1-click purchase of n suburb tokens per transaction, or $x worth of a suburb’s token will be enabled
Individual address points will no longer be rendered on a map, further decoupling the expectation of price to match a particular address. Instead, a n/n availability ratio will be displayed alongside the order book for that suburb
Subdivisions will no longer by attempted to be individually tracked. Instead, the dwelling count per suburb will be updated when available and announced to users - -The ratio of 1:10,000 per token may be changed to 1:100,000. Existing user accounts will be credited with 10x tokens to purchase additional suburb tokens based on existed balances