Curve Network

If your website is on the scam list and you think that you are not a scammer, contact us. After you provide us with all the proof that you are in Crypto World with good intentions, we will delist you. Usually, you get in this category because you are hiding your team, you have a bad reputation(you are tricking, deceiving, scamming people), and you haven't got a written project whitepaper or is a shitty one....

Their Official site text:

Summary
Welcome to the documentation portal for Curve
Welcome to the go-to portal for in-depth information about the Curve (CURVE) platform and ecosystem and how to interact with them!
The Curve documentation is separated into three major parts:
1. Curve Docs. This part is available in the sections below is for anyone who wants to learn more about Curve without going into detail that only developers would usually need to know.
2. Developer docs. Developers wishing to build on top of Curve and its mobile-centric infrastructure or run validator nodes should consult this .
3. Tutorials. This part contains various consumer-focused tutorials. It can be accessed here. ****
Curve Consensus
Consensus is a fault-tolerant mechanism that is used in blockchain systems to achieve the necessary agreement on the single state of the network. Curve network is using a  (DPoS) consensus model. DPoS is a variation of  consensus. In PoS there are a set of validators that are responsible for keeping the network updated and validating the network's state. They do this in turns, every validator has their turn in line. On their turn the validator updates the network's state, and the rest of the validators check that the update is valid.
Consensus contract is used to manage the list of the network validators and delegators
BlockReward contract is calculates the reward amount that validators and delegators will receive on each block validation. The reward size is proportional to validator's stake.
With Voting contract validators are vote on various changes on these 3 base level contracts. All those contracts are proxied with implementation that handles the logic. The implementations can be changed only by the Voting process.
The bridge is used to transfer the Curve native token between Curve and Ethereum networks.
​​
This contract is responsible for handling the network DPos consensus. The contract stores the current validator set and chooses a new validator set at the end of each cycle. The logic for updating the validator set is to select a random snapshot from the snapshots taken during the cycle.
The snapshots are taken of pending validators, who are those which staked more than the minimum stake needed to become a network validator. Therefore the contract is also responsible for staking, delegating and withdrawing those funds.
Stake amount for a validator is the sum of staked and delegated amount to it's address.
This contract is based on non-reporting ValidatorSet .
minimum stake amount = 100,000 Curve token
cycle duration blocks = 34560 (approximately 2 days)
​​
This contract is responsible for generating and distributing block rewards to the network validators according to the network specs (5% yearly inflation).
Another role of this contract is to call the snapshot/cycle logic on the Consensus contract
This contract is based on BlockReward .
​​
This contract is responsible for opening new ballots and voting to accept/reject them. Ballots are basically offers to change other network contracts implementation.
Only network validators can open new ballots, everyone can vote on them, but only validators votes count when the ballot is closed.
Ballots are opened/closed on cycle end.
max number of open ballots = 100
max number of open ballots per validator = 100 / number of validators
minimum ballot duration (cycles) = 2
maximum ballot duration (cycles) = 14
​​
This contract is responsible for holding network contracts implementation addresses and upgrading them if necessary (via voting).
Stake, Delegate and Withdraw
The basic requirement to become a Curve chain validator is to have a stake amount of at least 100,000 Curve tokens. The stake amount is the sum of staked and delegated Curve tokens of the address. This guide walks trough the process of using MEW (MyEtherWallet.com) in the process of using Curve network.Roadmap - Those functionalities will be built into our Studio and will not require any technical knowledge in the future.
Stake
There are two options to stake (both should be called from the address which would be the validator)
1.Send Curve tokens to the  - 0xC50Ca7Ead738F5501F5EF88F6015d7F09D238F95 on the curve network.
2.Call the `stake` function on the  - 0xC50Ca7Ead738F5501F5EF88F6015d7F09D238F95 on the curve network.
Delegate
Curve token holders who don't want to run a node by themselves but still wish to participate in governing the network can delegate any amount to one of the validators.Delegating is done by calling the `delegate` function on the  with the validator address as data (see screenshot from MEW).
delegate
Withdraw
Both stakers and validators can withdraw their Curve tokens, up to the staked/delegated amount, at any time. The withdrawn amount will be deducted from the validator stake amount, and if the stake amount becomes below the minimum stake amount - the validator will be removed from the Curve chain validators list.There are two options to withdraw:
1.Call the `withdraw` function on the  with one parameter - the amount to withdraw. This call is for stakers, and will reduce the stake amount of the sender address.
2.Call the `withdraw` function on the  with two parameters - validator address and amount to withdraw. This call is for both stakers (who can use their own address as the parameter) and for delegators to withdraw their delegated stake on a specific validator.
withdraw option no. 1
withdraw option no. 2
Vote
Curve chain functionality can be change by voting on the contracts implementations. New implementations can be deployed, and opened to vote by validators for others to decide on whether to accept/reject the changes.
Open a new ballot
In order to open a new vote, a validator needs to call the `newBallot` function on the  with the following params:
startAfterNumberOfCycles - number of cycles (minimum 1) after which the ballot is open for voting
cyclesDuration - number of cycles (minimum 2) for the ballot to remain open for voting
contractType
1 - Consensus
2 - BlockReward
3 - ProxyStorage
4 - Voting
proposedValue - address of the new implementation deployed for the relevant contract type
description - text description which should contain the reason/change introduced in the ballot
new ballot
Check ballot info
Everyone can check all the ballots that were created using the `getBallotInfo` function. This function receives two params:
id - the ballot id
key - account address
getBallotInfo
Vote
Everyone can vote on open ballots, after the start block has passed and until the end block hasn't yet.
It's important to note that at the end of a vote, only validators count towards the final result.
Voting is done by calling the `vote` function, which receives two params:
id - the ballot id
choice - 1 is accept, 2 is reject
vote
Some other useful functions on the  are:
getQuorumState
Returns the state of a specific ballot id: 1 - in progress, 2 - accepted, 3 - rejected
getAccepted/getRejected
Returns the number of accepts/reject of a specific ballot id.
activeBallots
Returns an array of active ballot ids.
End-of-Cycle Flow
This is a description of the End-of-Cycle flow that completes the Cycle and handles rewards and enforces the consensus
BlockReward.reward is called every block and when the cycle ends calls the Consensus.cycle
Consensus.cycle is responsible for several functions. Eventually does the following two actions:
Sets the boolean Consensus.ShouldEmitInitiateChange to true
Calls BlockReward.onCycleEnd which sets the boolean BlockReward.shouldEmitRewardedOnCycle to true as well
The primal-validator-app (fuseapp container on validator vms) checks the value of the above two booleans and when true calls the following two functions (two separate transactions):
Consensus.emitInitiateChange
BlockReward.emitRewardedOnCycle
Note that only one validator can make this call successfully so the 1st one succeeds and all others fail. But it’s ok because those are 0-gas transactions. So actually the validator who is the next one to validate a block is the one who is successful in making those calls.
The above calls emit the following events:
Consensus.InitiateChange
BlockReward.RewardedOnCycle
The bridge oracles fuseoracle-initiate-change and fuseoracle-rewarded-on-cycle are responsible for listening to above events.
Those oracles should run on all validators and call submitSignature on the HomeBridgeNativeToErc contract in primal network - each validator should submit the signature for each of the oracles (events).
Once enough validators have submitted their signatures (majority of the current validators), an event CollectedSignatures is emitted by the home bridge (again one event for each one of the previous events in section 4).
The bridge oracle fuseoracle-collected-sigantures is responsible for listening to the CollectedSignature events and all validators should get it. The validator responsible for transmitting the transaction to mainnet is actually the last one to submit the signature in section 7 and its address is part of the event details so other validator oracles “know” it’s not their turn and skip the event. If a validator is down or out of money or infura is deaf - the next one in line (in the ValidatorSet) is responsible for transmitting to mainnet.
Eventually on mainnet we are supposed to see two transactions to the ForeignBridgeNativeToErc each cycle - one updating the new validators and one minting the primal tokens which were created during this cycle on primal.
Note that if the new validator set transactions fail on mainnet there’s a chance the minting will fails as well, because before transmitting it checks if all signatures are valid and there can be a situation where new validators were added on a cycle and were fast enough to submit their signatures on primal end-of-cycle transactions but weren’t updated on mainnet due to failure of the 1st transactions so the 2nd one will actually contain “invalid” signatures from the mainnet perspective.
Example for a successful flow (from 7/6/2020)
Consensus.emitInitiateChange transaction on primal - ​
BlockReward.emitRewardedOnCycle transaction on primal - ​
How to become a validator
The Curve network is operated by validator nodes that are hosted by network participants from all around the world. The network allows entrepreneurs to easily plug payments to their products and on-board their users to a platform that allows them to pay, transact and access financial services in their favorite currency.
All the access to the network is public and all the code is open source so it could be customized and localized to their needs. Any community that lives on the Curve chain needs to pay a small fee to the validators of the network to validate its transactions in the community.
The more communities and users conducting transactions, the more validators will earn as a reward for approving the transaction. This allows the network to grow organically as more usage in the system more network participants rewards grow.\
What it means to be a validator?
​ that approves transaction in the network and in doing so receive rewards in the form of Curve token (CURVE).
Validators are running special software that holds a copy of the Curve blockchain and validating transactions in the network.
Every 3 seconds, the network groups the latest transactions broadcasted to the system, validates them and signs them so they could never be changed in the future.
For this work the validators receive block reward (X per block). A yearly inflation of 5% is distributed between all validators (the block reward is updated to accommodate this functionality).
Validators are contributing their computer resources to maintain the network and need to have some technical knowledge in dealing with hosting this kind of software (see ) and .
Validators are the guardians of the network and are in charge of not only maintaining it but also to steer it in its future through the governance mechanism that allows any holder of Curve token to vote on important decisions and upgrades to the network in its development and resource allocation.
Who should become a validator?
Companies who build on the network - Curve open source stack allows many companies to collaborate on the same code-base.
Allowing any company that is interested in using the Curve services and code to join as a stakeholder is a new innovative approach to collaboration and partnerships.
Any company that builds products on the network can own a piece of it and become a stakeholder.
Running a node in the process will allow the company to earn rewards and grow as the network grows.
The company can also use this open-source infrastructure to save costs for their development needs.
Operating a node gives reliable access to the network, participation in its governance and aligns all the different interest behind the operation of the network.
3rd party service providers - We are starting to see many service providers creating and providing services across different blockchains. Services like KYC, exchanges, credit score providers, lenders, etc…
Any service provider can become a stakeholder in the network and already today we are seeing the potential of cross-blockchain transactions uniting business processes between different entities using cryptography and without middlemen.
Community operators on Curve - Community operators are the foremost stakeholders in the network and can upgrade themselves to a validator and thus provide better access to their clients.
Who can become a validator (Technical requirements)
See __
Who shouldn’t become a validator (and what can he still do)
Non technical users - Running a node requires technical background in blockchain and web hosting. It’s not very complicated but also not trivial or basic.
Simple holders - We are looking for validators who are invested in the future of the network and are looking to take an active part. This is what the DPoS (Delegated Proof of Stake) mechanism was born to do.
​ of your choosing. Not everybody that wants to earn rewards need to be a validator! Any token holder can delegate their Curve token to a validator to earn rewards through the validator.
How to become a validator?
Minimum of 100K tokens staked or delegated. In a DPoS blockchain it is required that all the validators have a staking requirement. The stake of 100K Curve tokens needs to be locked in a contract to be eligible to become a validator.
Run a full node.