The thing to remember about the SBC is that there were no stipulations about what the funds could be used for. They were awards for existing work.
I didn't realize that. I can certainly imagine the horror of many ICO projects last year when Ethereum crashed 90% and they no longer had the funds to complete the ICO work. That surely must have disrupted a great many projects.
deylandra Fair question. I thought I did my due diligence, drew up a contract, and hired someone who claimed loads of prior experience, but I should have looked more into his references. This is just one of those things where I have to take my lumps and learn from it, and as odd as it may seem I'm actually glad it didn't happen with a larger contract. I'll be much more skeptical in the future when hiring.
I guess there can be two schools of thought about what the SCF should be used for: do you award people as a thank you for doing good work and that's that, or do you award them so that they can hire people and accelerate development? It's probably a mixture of the two but as a voter I'd definitely lean more towards the latter.
As for my family and work, it definitely gets in the way! I'll readily admit that I wish I had more time to work on this. I do hope to get to a point - through SCF, other developer programs, or an eventual paid version of StellarGuard with pro features, where I can end up working full time on it AND hire others to do it.
For the Anatomy a Scam, check out the first one if you haven't already: https://medium.com/@stellarguard/anatomy-of-a-stellar-scam-the-hard-fork-4ac89808fd38, it's less about pointing out a single scam and more about giving you a framework for detecting them yourself. It's that sort of thing I'd like to continue with -- teach a man to fish... you know how the rest goes.
Good luck on your submission. I hope if it's a project that you're passionate about that you continue to work on it even if you don't win. StellarGuard did not win the first time I submitted it and I continued to work on it -- don't let it discourage you!
I actually can feel your pain and relate. A programmer I'm building language software with had an unexpected pregnancy and he did not have insurance for it (they thought he was infertile due to past medical issues.)
I was supposed to pay him $10,000 upon completion of the work, well, his wife goes into labor and he's like I really need the money now, I have to pay the hospital bills.
Well I've known him for over 10 years, always did great work, so I pay.
For six months I don't hear from him. Turns out he's having major financial problems supporting his wife and three kids, all of his time is spent getting jobs for immediate income to just barely get by, so he hasn't had time to complete the work for me cause it's not going to bring in immediate cash since he already got paid.
After six months, he completes the work, but it's a rush job and it doesn't function right, so I'm having to redo most of the work myself. He has complained a lot about getting stiffed from people he does jobs for over the years, I think it's very common on both ends.
In the future I will use escrow. That way the programmer/contractor doesn't have to worry about getting stiffed and vice versus.
Agree on smaller tasks or milestones, 50% upfront, 50% after completion of task/milestone. Works for me. I often pay weekly or bi-weekly. But I think this is not the place to discuss this, maybe a mod can move or remove our off-topic posts 
Okay, okay, how about calling it WIFEGUARD and then doing an Anatomy of how to keep your wife from spending your money.
I would totally vote for that.
We definitely went off the rails with this conversation! Can we please just talk about Rampart... err... StellarGuard?
I've been thinking more about throttling implementation, and I believe it makes sense just to add the rules engine right from the beginning.
Some simple rules to start are exactly those throttling rules mentioned before, but it opens the door to much bigger things.
Examples:
Allow sending at most 100 XLM per day, or reject the transaction.
When sending XLM to <G....> do not require approval.
For any payments over 1000XLM, require 2 factor auth token.
The devil is in the details and I want to take some time to get this right, but I wanted to start getting some feedback about what sort of rules you might actually use, given this capability. Especially interested in how Stellar bot users might use this.
I've started implementing automated signing policies more times than I can remember. It always the communication layer needed that stops me from doing something more general purpose.
So, yeah, I'm a huge fan of that kind of functionality. I'm not sure if the general ecosystem is ready for it though, we might still be very early.
Would be nice to see CosmicLinks put at use here 
StellarGuard We have been following the development of StellarGuard for a long time - we accept your offer to work together! As soon as the dust from the competition settles, we will look under the hood and play with your technology and, if possible, it would be cool to apply it in our project Scopuly.
Scopuly Great to hear! Let me know if you have any questions when the time comes.
One side effect of building out a rate limiting/throttling engine is that I'm able to repurpose it for other forms of throttling, not just payments.
In fact, tonight I'll be rolling out the first of those changes: you will not be able to use the same two factor authentication code more than once, even if it is still valid for the current 30 seconds.
This is a security measure to protect you from phishing: imagine an attacker sets up a clone of stellarguard.me, called steIIarguard.me (those are capital ii instead of L) and you fall for it and enter your username/password and a two factor authentication code. The attacker may gain access to your account, but if you have your security mode set to "high" they will not be able to perform any payments/account settings changes without entering a brand new valid two factor auth code, not the one they just phished from you.
This is just one small security improvement that I've got planned. Much more to come!
I've launched the first usage of the throttling engine to throttle sign in attempts (6 per minute) and prevent re-use of 2 factor auth codes.
While I was waiting for a new Redis instance to spin up, I decided to write about a topic that has been in the back of my mind for a while. It's called "Stellar - What's in your Wallet" and it goes into a brief discussion about what functions your wallet actually performs and how it interacts with the Stellar network: https://medium.com/@stellarguard/stellar-whats-in-your-wallet-1b07b8f7123a
