Wiki document with some proposals for core implementation of token locking/unlocking, command implementation etc. is created here: https://github.com/safex/wiki/wiki/Safexcore-advanced-functionality.
Reviews and comments are welcome.
Hello Marko,
Nice to have you now on the forum as well!
Fee collection will happen in the token unlock procedure, where calculated interest will be output of the transaction together with the unlocked tokens that return to their holder as UTXO. ā¦ Alternative solution to regularly distribute fee to all token holders with locked tokens is abandoned because of the high cost and possible big number of token holders.
Is there literally no way of distributing fees in a more regular process? My proposal would have been the following in addition to your proposal:
Example:
minimum lock-in duration: 1,000 blocks
payout intervall: 10,000 blocks
Person A locks their coins at block 100,037
Person B locks their coins at block 100,123
Person A receives payout at block 110,037
Person B receives payout at block 110,123
In case of more ongoing transactions on the network, the payout intervall gets increased in order to ādiluteā div payout tx ratio in the network.
New payout intervalls: 20,000 - 50,000 - 100,000 blocks (depending on tx traffic)
Additional proposal:
If necessary, unlock (you get the joke?) this additional feature for a minimum locked in token number per address only - like a bonus for early investors.
Mininum amount of locked in tokens for continuous payout bonus feature:
10,000 SFT - 50,000 SFT - 100,000 SFT (depending on actual tx payout numbers in the network)
My speculation: The higher this minimum token number for this bonus feature is set, the less addresses will fulfill this requirement, which again leads to a decreasing number of continuous div payout transactions in the network (in addition to the āregularā payout transactions via SFT lock out).
You could also play this out gradually. Example:
address 1 has 10,000 SFT locked in: payout only via SFT lockout (too many addresses in this range)
address 2 has 50,000 SFT locked in: additional payout every 50,000 blocks (fewer addresses in this range)
address 3 has 200,000 SFT locked in: additional payout every 25,000 blocks (ā¦)
-and so on-
Another possibility would be to automatically payout after a certain amount of SFX is reached - for instance 100 SFX. This would lead to the same result of fewer automatic payout transactions. Say (Payout for address 1 if 100 SFX is collected). Naturally this will take more time for smaller wallets (big in numbers) and less time for bigger wallets (few in numbers). If tx traffic is increasing, adjust SFX amount for automatic payout to a higher number -> 500 SFX.
Basically, the idea would be to construct the minimum collected SFX amount necessary for automatic payout as a function of GMV/tx number on the blockchain in the last xxx blocks (direct proportionality).
In all these scenarios, you as a locked in token holder would still pay the fee for the bonus automatic distribution.
Example:
Minimum bound for payout: 500SFX
Block y: 490.xxx SFX collected - > no payout
Block z: 501.xxx SFX collected - > payout
1.xxx SFX go to miners to include tx in pool
500 SFX get distributed to lock in address
(I came up with this additional idea (minimum bound for SFX) just right now, this may actually be the easier approach for integration, but heck I donĀ“t know anything about coding.)
I came up with this idea from staking wallets, where you receive your stakes more regularly the more coins you have in your staking wallet. If you have a big staking wallet you can collect every few hours, if you have a smaller staking wallet you receive your stake after days/weeks. I know, this is no staking but the result is the same.
Regards,
Oliver
4 Likes
Hi Oliver,
thanks for interesting thoughts. We have considered regular payouts at first - well, the main problem is scaling and transaction cost. There is over 2 billion tokens available, and if minimum token amount for lock is 10k, there could be up to 200k token holders that should receive payouts. If payout is every 10000 blocks (around two weeks), network would be overwhelmed with the huge pile of payout transactions. It is not feasible at this level of core protocol bandwidth.
Second problem is cost of transaction fee for miner to include payout transaction in the block. Current minimum network transaction fee is 0.02 Safex Cash, and if earning for token holder is smaller or comparable to this amount there is no point to do payout.
Idea with minimum amount for payout is interesting. Let say that minimum payout amount is 100 Safex Cash, and that miners could create and include such payout transaction in the block if token holder should receive more that 100 Safex Cash. On the other hand, it would technically complicate things, because additional bookkeeping must be done on all nodes to track who of the token holders has earned enough for payout and who has already received payout and should wait more for next payout. Constant checking who of the 200k token holders has enough money for payout and payout transaction fee (because every one of them could lock tokens any time), would be significant burden for nodes in terms of processing power.
Manual lock/unlock and payout collection is technically probably by far most simple thing to do as a first implementation, for the first protocol version. But there is no obstacle to include more advanced/optional payout models in some future protocol version, and we should definitely think about that.
Regards,
Marko
3 Likes
Also, one more thing that may be important to some token holders. By doing manual token lock/unlock, you preserve your privacy with the ring signature of the token input and random public key of the locked token output. If automatic payments are used, every token holder would have to publicize his address where he wants to collect payouts.
4 Likes
@markoatana requiring a manual token unlocking to receive distribution seems like a reasonable first approach to me. better to take a simple approach starting out.
Thinking ahead, could a SFX payout sidechain be implemented that strictly handles processing fee payouts? If all transaction fees could be sent to a sidechain, a different group of miners could process the sidechain transactions which would free up the main chain entirely from the business of payouts while also making it possible to rapidly distribute to SFT holders since doing so wouldnāt impact the main chain.
1 Like
Thanks for the detailed reply!
Thatās exactly what had me worrying. How is this solved in PoS systems? Another thing to keep in mind: As far as I know in normal PoS algorithms (DASH, NEO, etc.) the reward of one staker is not influenced/altered by the number of other stakers in the system. Since this is not the case for Safex, this would make the SFT/SFX bookkeeping much more elaborate. Anyways, Iām excited how it turns out to be working either way.
1 Like
āManual lock/unlock and payout collection is technically probably by far most simple thing to do as a first implementation, for the first protocol version. Also, one more thing that may be important to some token holders. By doing manual token lock/unlock, ā¦ā
Help me have the concept clear, to collect incentives we must unlock?
2 Likes
@ulrich95 Could you elaborate more? What would be advantage of side-chain for this purpose? In which way would it remove weight from the main chain when certainly you have to sync balance of every token holder on the main chain eventually?
2 Likes
@eddie995it
When you put it that way, it does sound tedious 
Beside lock and unlock, we should introduce third type of command that should ārelockā tokens atomically. So you would collect interest and restart token locking period from that block in a single atomic transaction.
3 Likes
Thank you for the clarification. It will be somewhat pricy depending on collecting frequence and size of the bag, but itās doable. 
1 Like
Leaves it up to the user to decide how often they feel they would want to withdraw in such a case.
And at their own speed, no need to wait for anyone elseās interval. I like this approach the most.
6 Likes
The idea to ārelockā is nice. It keeps it simple for the end user and could maybe just be named ācollectā.
6 Likes
Yes balances would need to be synced but if the SFT are locked on the side chain, the SFX fees could be transferred to the side chain every 10000 blocks in one transaction and distributed there to the wallets. Then you could require a manual transfer back to the main block chain and only allow one transaction per wallet per day (or even less), to limit the number of transactions. To make sure itās a human initiating the transaction from the side chain back to the main chain, you could issue a recaptcha challenge or something similar which would cut down on people creating many small wallets to get around the transaction limits. Another way of controlling the impact of transferring SFX back to the main chain would be give those transactions a low mining fee so they have a lower priority and take longer to complete.
There might also be potential benefits a side chain would give you over controlling the flow of SFX. Do you think your Chief Economist Ivana would be interested in being able to do that? Imagine if the system decided the price of SFX/BTC was too low and so it wanted to restrict the flow out from the side chain back into the ecosystem by somehow incentivizing SFT holders to keep the distributions on the side chain for longer periods. The system could also decide the price of SFX was too high and deincentivize holding it on the side chain to increase the flow of SFX back into the ecosystem. Just brainstorming here.
Whatever you decide Iām sure it will be great!
3 Likes
Side chain ideas have been explored substantially in July-September; there is a lot of work and testing needed in such a system. For example: Lightning Network on Bitcoin has been under development for 4 years.
On chain is a proven architecture; we prove like this. In my view we can pursue a parallel network for marketplace and all: with more developers on board
5 Likes
This is a good approach. Build a solid foundation first, when revenue on the market grows and developer team expands, further possibilities may be looked into. In the first stage of the market, scaling problems because of too much tx traffic will not be an issue I guess.
4 Likes
I had a couple more thoughts about the mechanisms that could be used on a side chain specifically around being able to ācorralā SFX in the side chain at opportune times, or to cause SFX to circulate out of the side chain when liquidity is needed. Maybe something to think about for the future. There maybe times where SFX liquidity is low or the SFX/BTC value is not optimal from the perspective of encouraging commerce which is what the Safex Markeplace is all about.
To restrict supply/circulation, any SFX held on the side chain (which would only be SFX distributed to SFT holders), a percentage of the mining rewards could be taken from miners and distributed to SFT holders on the side chain based on the percentage of SFX they hold on the side chain. That would restrict SFX supply and flow by discouraging mining while also encouraging SFT holders to keep SFX on the side chain.
The increase supply/circulation, a percentage of marketplace distributions could be sent to active miners for each block mined, instead of going to SFT holders. That would encourage mining and increase the supply. It also might be possible to get SFX moving off the side chain if there were a way to decrease the marketplace payout to SFT holders based on how much SFX theyāre holding on the side chain. That would at least get SFX off the side chain and possibly some of it would make it back into circulation.
Thereās probably a more elegant way of handling this than what I described and Iām sure doing these things would require a lot of research and development effort.
It would be interesting to know if Ivana thought there could be value to controlling the supply and circulation of SFX in some manner.
I really like the idea of the user deciding when to āclaimā their SFX incentives.
As people have mentioned, this would spread out the incentive transactions over a number of blocks, rather than all in a single block. This is nice to reduce congestion on the blockchain.
BUT, an additional benefit from my perspective is more control over personal tax obligations.
For example, in my country it is likely that SFX incentives will incur a 33% tax. This tax is calculated based on the value when it is awarded to the user.
So if I decided to claim SFX incentives once a month then this means I only have to do 12 tax calculations to find my obligation, rather than 365 if it was distributed automatically daily.
This is actually quite useful.
4 Likes
I wonder if the wallet can just have some scheduling functionality, you preset say, X number of āClaimsā to occur on a given day/date each Xperiod for Xnumber of periods. Just like you can with your internet banking, it might need the wallet to always be running though I suppose.
2 Likes
Exactly as safeyfirst references - if this is going to be a āmanual unlockā, why not let us automate when we want our manual unlocks to be for ourselves? Instead of āclick button for distributionā why not āTrigger manual distribution at (X criteria) per (y timeframe)?ā X being: distribution amount, market volume, whatever we can feed in.
There is an entire thread on this subject here: Locking and unlocking SFT yearly
It explains the development requirements and constraints with blockchain technology. Worth the read from the start to the end.
1 Like