ARK delegates

Discover and follow ARK delegates



  • Is public delegate?
  • Voters: 56 (48 )
  • Voting power: 1,016,525.8
  • Payout percent:
  • Payout interval:
  • Payout MIN:
  • Payout MAX:

My proposal

I am here to present a unique delegate proposal for the Ark Ecosystem. I have been working for the last months to fix several important security vulnerabilities in Ark Node v1 and Ark Core v2 and I'd like to continue doing this, because I think it's beneficial for the future of the ecosystem for obvious reasons.

The forging rewards from delegate alessio are used to cover the funding necessary to continue my security research and code auditing for Ark Core v2 on a permanent and full time basis. All discoveries are confidentially disclosed to the Ark team who pay bounties for all confirmed vulnerabilities that are reported. These bounty rewards are then shared in full with the delegate's voters in proportion to their voting weight at the time the bounty is received.

Past experience

I worked in a team to recover the Ark Node v1 mainnet chain in October, where my duties involved writing a patch to hard fork the network, taking a clean snapshot of the blockchain (which all delegates subsequently used to restore the chain), delivering an airdrop to the delegates and retransmitting all existing transactions to ensure that no funds were lost and that no transactions could be maliciously replayed.

After that, my focus switched to Ark Core v2. You can read about some of my discoveries in the Updates section below, or by checking the official security-vulnerabilities repository on GitHub here: The vulnerabilities reported by fun or alessio are mine.


In summary, I've spent many hours auditing and investigating security issues in Ark Core v2, with a proven record of repeated success and I've reported more v2 security issues than anyone else. I can only continue this work with a regular funding stream from forging rewards to cover the hours that are spent on it, and in return, the delegate voters receive their share of any bounties I get, based on the vote weight of their wallet at the time the bounty is received.

Security should be a massive concern for any cryptocurrency and I have hopefully demonstrated my skills in that regard. We need to keep the codebase secure, and this extends beyond Ark alone, as we need to think about all the other forks based on Ark and the future push-button blockchains too if we want to see mass adoption and ultimately succeed.

And if you agree with me, please consider voting for delegate alessio.


  • Security research, vulnerability discoveries and patches
    Please see the Updates section below or the list of vulnerabilities here: All vulnerabilities reported by fun or alessio were made by me.


  • 19. Mar. 2019 @ 17:59 | visit update page
    Core-SV-014: Public API endpoint open to possible DDOS attack: Endpoint /api/v2/delegates/{delegate}/voters/balances did not paginate its results. This was a vector for DDoS as anyone could request the vote balances of every voter of a delegate in one API call. For delegates with large number of voters (>5000) this could overload the server even before the HTTP rate limiting kicked in.
  • 14. Feb. 2019 @ 14:42 | visit update page
    Core-SV-013: Transactions near to the HTTP POST payload size limit can stop delegates forging and halt the chain: The maximum HTTP POST payload is 1048576 bytes but there was no logic to ensure that blocks only contained transactions that would fit in a block below that size limit. It was possible for any network user to send deliberately oversized transactions that would approach (but not exceed) this limit. Although nodes would accept these larger transactions as valid, when it was time to forge them into a block, the additional block headers would make the block size larger than 1048576 bytes. This meant all nodes would reject the block with HTTP error 413 Request Entity Too Large, so the forging node would miss its block and the oversized transactions would remain in the transaction pool, meaning the node would be unable to forge until the oversized transactions expired (the default time being 6 hours).
  • 11. Feb. 2019 @ 21:58 | visit update page
    Core-SV-012: Conflicting delegate registration transactions not detected by the transaction guard: A user could try registering the same delegate name using multiple wallets in a single block. It would result in a stalled network because no delegate would be able to forge a valid block as they would all try to forge blocks containing the conflicting transactions. If exploited maliciously, any bad actor could have stalled the network permanently by repeatedly sending conflicting transactions to ensure the transaction pools were never clean so the network could not recover.
  • 01. Feb. 2019 @ 00:37 | visit update page
    Core-SV-011: Malicious delegate 0-ARK transaction spam: The transaction schema to prevent zero-amount transfer transactions was never enforced by consensus, so zero-amount transfer transactions could be sent by a malicious delegate to spam the blockchain.
  • 01. Feb. 2019 @ 00:35 | visit update page
    Core-SV-010: Malicious delegate can cause peers to fork and roll back simultaneously: A malicious delegate could craft a block at the correct height but with a timestamp from a previous round that collided with a valid forging slot time for that delegate in the current round. This has the result that the block would be initially accepted, but, because the block was unchained due to the incorrect timestamp, it would cause the receiving node to immediately enter fork recovery mode and roll back the chain.
  • 01. Feb. 2019 @ 00:34 | visit update page
    Core-SV-009: Fake peers can be added by using non-quad-dotted notation: Peers using non-quad-dotted notation representation could be added to peer lists, which provides a denial of service vector as millions of IPv4 loopback addresses could be added to the peer list which will all resolve to the local node which would overwhelm the server.
  • 25. Jan. 2019 @ 18:43 | visit update page
    Core-SV-008: Forged blocks by anyone can cause the chain to stop/or start recovering: Anyone can broadcast signed blocks, and when receiving a forged block from a wrong generator, the chain would fork. This also applied to inactive (unknown) generators. If a malicious actor kept broadcasting such blocks, the chain would effectively cease operating.
  • 25. Jan. 2019 @ 18:43 | visit update page
    Core-SV-007: Forging multiple blocks in a slot and rewards hijacking: Any active delegate could forge multiple blocks within their allocated 8 second slot time, as long as the block IDs were different and were all sent to the same node with an incrementing block height, as each block was considered to be valid and accepted on the chain. This had the effect of generating block rewards for each of the multiple blocks that were forged in the slot, resulting in inflated rewards per round for any delegate that carried out this exploit.
  • 25. Jan. 2019 @ 18:43 | visit update page
    Core-SV-005: Double forging a block: A malicious forger could forge multiple distinct blocks and broadcast them to different peers causing instability in the network.
  • 25. Jan. 2019 @ 18:42 | visit update page
    Core-SV-004: IP spoofing: The whitelist could be bypassed by IP spoofing due to the way we determined the IP of a request. This could also be used to fill up the peer list with loopback IP addresses to cause a DoS attack and prevent block propagation.
  • 25. Jan. 2019 @ 18:42 | visit update page
    Core-SV-002: Generating new Ark using multi signature transaction: In a multi-signature transaction, the transaction handler only verified the signatures and did not properly conduct balance checks. This made it possible to generate new ARK tokens on the network utilising a multi-signature transaction.
  • 25. Jan. 2019 @ 18:37 | visit update page
    Core-SV-001: Invalid block received: The lastDownloadedBlock variable was not reset when discarding invalid blocks. This caused network nodes to continually attempt to download new blocks from the wrong height, effectively halting the network. This issue would have allowed a malicious user to disrupt network nodes and the network itself.


  • CPU: 8
    Memory: 16384
  • CPU: 4
    Memory: 4096