I'm still new to circuit design so trying to wrap my head around I2C and how to use it. If I'm building a shitty add-on can I use the SCL signal as a trigger to blink lights or do I still need a 7555 or is there a better way to do that?

there are a lot of ic's that use i2c to communicate, what you want to find is one that is either a GPIO expander or something similar. The mr.meeseeks SAO uses a MCP23017 

Then once you connect leds + resistors to each pin. but this is all reliant on the badge knowing what your i2c address is and sending packets that the mcp23017 would interpret into led blinky patterns, ie. sending it binary values which correspond to ascii numbers, but when translated to binary represent each led as a bit of that byte. ie "3" would be 00000011 so whatever was connected to pin 0 and 1 would be on and everything else would be off. :) hope that helps to explain. 

Created shitty add-on scanner / debugger. This would print over UART all the "Friendly names" for the badges. Tries to read and write to all devices found.  https://github.com/sajingeo/b617/tree/master/gadget_test

Please email drew@oshpark.com if anyone would like a batch of add-on's made for no cost.  Drew will be at Defcon and wants to make sure everyone is well stocked with fun add-on's :)

So obviously this is shitty, but power's a concern. I'd clarify 3v3 if that's a requirement vs VCC.. VCC is ambiguous and I suspect lots of badges will be 5v VCC.  It's also a lot harder to go back up to 5v than down to 3v3 from 5v.

As far as I can tell, most of the #badgelife badges are going to be 3.3V.  That's what we're settling on, I guess /shrug.

Also, this is the *shitty* addon. If you want guaranteed voltages and the ability to sink a set amount of current, make your own standard. This is the one where we go, 'yeah, that'll probably work.'

"Find some batteries in that one drawer that never opens because there's a potato masher or something in there." how do you know you've never been to my house lol

That's what you think...