signum-network / business-epics Goto Github PK

Polarity is a DEX driven by our friends from TurtleNetwork. As BPSAA member we have special conditions.

A user should be able to see and create his subscription on Phoenix on both versions mobile and desktop.

• signum-network/phoenix#1400
• signum-network/phoenix#1545

With the goal to have more and more use-cases and business-cases on the chain, we should also support the buy-out/transfer of a business to a new owner.

As the current setup a token and his corresponding transaction, like minting, set Treasury-Account is bind to the creator account.
As the passphrase can´t be changed, we should introduce a new transaction TransferAssetOwnership.
With this the current owner (which is by creation = creator) can enable another account to be the new owner.
After the transaction is added to the chain, the smart token owner will change to the new owner, and only this owner can do the following:

• Mint token
• Set Treasury-Accounts
• Set new Owner

The minted tokens will always add to the current owner account on the token.

If you provide a node as localhost or as remote provider for a wallet (like Phoenix) for example you should get a reward for every transaction which is created via your node.

Proposal:
If a tx is genereated with the node the account from the node is included into the transaction as an extra field. When the transaction gets added to a blokck, X% (to discuss) of the fee is going to the node account owner- instead to the miner.
The logic will be added to the node and needs a HF.

As a side effect - we will see a lot more local nodes used by people (for own discount on the fee) and also a benefit for node provider to be used by Phoenix or BTDEX for example.

https://github.com/signum-network/SIPs/blob/master/SIP/sip-43.md

We need addtional token features to be more up to date:

• Flexible in number of tokens
• Cap yes/no
• can be mint or burned by creator

Description
A user should be able to borrow Signa coins for his mining activities.
Both sides miner or holder should be able to create an offer to lend or borrow Signa coins.
A offer will be set by:

• Amount of coins
• Number of blocks for the lend/borrow
• Lending-Fee which would be paid

We would have the following new transaction types:

• Place a lending offer
• Place a borrow offer
• Cancel a lending offer
• Cancel a borrow offer
• Take a lending offer
• Take a borrow offer

The coins form the lender will never leave his wallet.
When an lending offer is created the coins get locked on the lender wallet until the offer is cancelled or the offer is taken and the lending time is reached. The lending-fee is paid upfront to the lender.

A miner which took an offer has the following limitation to get the borrowed coins added virtually to his commitment:

• 10k borrowed coins regardless of the commitment can be added to the virtual commitment
• Only in a ratio 1:3 can be the virtual commitment be added in relation to the own commitment.

( Example if the miner has 500k committed - he can add another 1M coins via borrow)

A user should be able to uplaod a smart contract via deeplink function on Phoenix.
A generic window should be open in Phoenix to complete the action.
It should be possible to upload the machine code and a data load in one call.

• signum-network/phoenix#1546
• signum-network/phoenix#1547

A smartcontract should be able to handle tokens wihtin the code base.
The following function should be supported :

• Creating a token
• Transfer token to and from
• Check token balance for other accounts
• Place buy and sell orders on the internal token market from Signum
• Check open orders for a token
• Mint and burn token ( see #5)

With the SNR (Signum Network Reward) a bonus was introduced to Signum Node operators for keeping up the Signum Network. The system is well established and we will continue with this setup.

However, based on this setup we would like to introduce another level of decentralization and give a reward for node operators if those nodes are used for transaction generation.

How does this work ?
If a user is generating a transaction with a node (local or remote) the node will check if on the P2P.myPlatform or a new config parameter (to discuss) in its config a valid Signum account address and will attach this account to the transaction.

When the transaction gets processed a part of the fee is paid to this account instead to the miner - if no account is attached all fees go to the miner.

Adjusting the minimum fee
In CIP-03, the minimum fee was changed from 1 Signa to 0.00735 Signa.
To give a fair amount to the node operator we would change the minimum fee to 0.01 Signa and pay 26.5% to the attached account. This way, if you run your own node you will still pay the previous minimum value of 0.00735 Signa. Recalling that CIP-31 introduces a “per byte” fee basis and that will still apply.

We would achieve two goals with this - getting more human friendly looking minimum fees and also being able to pay a good portion to the node operator´s account.

This change would require a hard fork.

Signum is to get its own browser extension, for Firefox, Explorer and Chrome.
Basis for the development should be this repo

The extension should allow the user to connect to his wallet within the browser and execute all common transactions that are possible via the Signum blockchain.

The browser extension should be an own repo on the Signum-network

https://github.com/signum-network/SIPs/blob/master/SIP/sip-42.md

The chain should be able to fill the blocks by the given transactions sorted by the fee ( high first - low last)
In this case we would avoiding that transactions like reward assignment with the current min fee are waiting many blocks beside it could be direct transmitted as the block is not fully used.

The minimum fee should be calcualed by minFee = FEE_QUANT * (transactionBytes / 176)
This would lead to the following :

• Ordinary TX send: 176 bytes, pays FEE_QUANT
• Add commitment: 184 bytes, pays FEE_QUANT
• Deposit to Bittrex (with the memo): 245 bytes, pays FEE_QUANT
• Place token order: 201 bytes, pays FEE_QUANT
• TX send to extended address (with public key attached): 209 bytes, pays FEE_QUANT
• Multi-out with the max receivers: over 1200 bytes, pays 6*FEE_QUANT
• Message with max attachment: over 1200 bytes, pays 6*FEE_QUANT
• Create subscription: 181 bytes, pays FEE_QUANT

For the following transaction types we would add a higher multiplyer with the minFee:

Phoenix should have the same layout and functions on Android as on IOS

• signum-network/phoenix#1548

Description
If you start to create smart contracts for an application on the chain you can either go the way that the smart contracts are only issued by your account and you handover the ownership within the smart contract to ensure the correct code.

Another way could be that you want to ensure that only smart contract with your original code is taken into your application.
To be able to proof this every smart contract will get a hash for his machine-code on the node (created by the node with a given function).

Now a user can verify via a new API call if the smart contract XYZ is with the same execution code he wants by just comparing the hashes (his original hash and hash from the SC on the chain)

Implementation Details
To enable scripts and user to proof SCs we need the following items:

• New table entry with the hash on the Node-DB
• Function for the Node to create the hash
• API call to get a hash for a single SC
• API call to get all SC with a given hash
• API call to handover machine-code and get the hash

All exisitng SCs need tio get a hash entry when the node starts the first time

As member of the BPSAA alliance we are looking forward to establish interoperability between the different members platforms like PirateChain, Ergo, Sentinel, Dragonchain, ETH0, TN etc.

In this first step we want to establish a simple interoperability between Signum and Dragonchain.