With a lot of talk happening around UIA (User Issued Assets) on Steem, I decided to spend a day experimenting with how we could use some of the existing data storage here on the Steem blockchain to actually run an ICO-like event. Without actually having smart contracts like ETH, the service itself I wrote is a sort of "fake" smart contract that runs much like a bot would, using [steem-python](https://github.com/steemit/steem-python). It's no where near as secure as a real smart contract however, as you actually have to trust the user running the script to do you right. 

The source code is [available here](http://github.com/aaroncox/icoman).

At this early of a stage, it's only function is to process incoming transactions, ensure they're valid, and make an trail of transactions that could then be audited to prove participation. The goal is to explore how we (as a community and as developers working with Steem) can raise funds to help kickstart projects without having to tap into the rewards pool so much. Imagine how much it would contribute to Steem's success if we had a dozen teams all working on their own individual (and funded) Steem platforms!

As a note, no one should expect to download this script and use it as is :)

## Concepts & Theories

### Channeling between two accounts

The current model I have setup uses two accounts, a `donation` account and a `processed` account. Each transaction between `donation` account sending to the `processed` account is considered as a "valid" donation for the purposes of these fake ICOs. Any funds that are just sent to the `donation` account while the script isn't running (to process it) or any donations send directly to the `processed` account would not be considered valid for the ICO, and would end up being purely untracked donations. 

The `donation` account is a funnel which receives all donations for the project and processes their validity based on:

- start block
- end block
- currency type (steem/sbd)

It also is the account that stores the state of the event within it's `json_metadata`. The donation account's goal is to never actually hold onto funds for more than a minute or so (while waiting for irreversible blocks), so that if it gets compromised, there are no funds within it.

The `processed` account is the final destination of all valid funds, and only funds sent from the donation account are considered valid. This account should have it's keys locked up tight (not in a script like this), and probably using multi-sig for it's owner/active keys. 

### State storage & persistence 

Currently to maintain an index of donors, the script updates it's own state to the `json_metadata` of the `donation` account upon activity, at most once a minute. Any block explorer will show this data, and it would be very easy to build a live updating webpage for an ICO that just continually reloads the `donation` account and parses it's `json_metadata`. This provides an easy way to see who has donated and how much without having to replay the entire sequence of blocks to build an index. 

Ideally, that's what should be done though, building an index that monitors the start and end blocks, then builds a donor list based on the transactions between the `donation` and `processed` accounts.

The `json_metadata` field has limitations, mainly related to the maximum block size on Steem. Quick estimates show that approximately 2000 account could donate using this method before the `json_metadata` field for the account fills up. So that's a challenge to overcome. Luckily since the transfer between the `donation` and `processed` accounts is the actual operation of record, the overall donation log could be audited and rebuilt even if it filled.

### Bandwidth(gas) for transfers

The script is intelligent enough to queue/batch all transfers, and upon a failure to send, reports the failure within the console and retains the operation for when enough SP is available. Every 10-15 seconds it attempts to process all ops within the queue, and will process as many as it's currently allowed with it's bandwidth.

If the account itself see's a massive amount of transactions during the ICO - more SP may need to be delegated to the account in order to allow processing of all of the transactions.

### Transferability & Tokens

This setup currently doesn't support the ability to transfer ownership of tokens OR even the existence of tokens. 

The hope is that if UIA's end up coming to Steem, this workflow model could be adapted to actually issue tokens upon creation, thus solving both of these challenges.

### Expanding into `custom_json` ops

Things could get very interesting with more work on this concept and the expansion into `custom_json` ops within the blockchain. The ops themselves are still bound to the limitations of the block size, but these ops could be used for transferring ownership (before UIAs), maintaining state, and setting parameters of the event.

## Future Plans

I'm planning on continuing the exploration of these ideas, and am looking forward to seeing what sorts of ideas the community has around this concept. Making an announcement post and simply asking for donations works to some degree, but having a real system where we could run crowdfunding events for projects within the blockchain would be an incredible step forward.

Once I have a little more stable version of the script, I'll probably setup a test to stress-test the bot and it's performance to see how it does. Priorities are elsewhere for the time being though, so I'm not sure when I'll revisit the concept.