Contracts, keepers, and the failure paths in between

Lotix — verifiable raffle protocol

Anyone can create a raffle by escrowing a prize (an ERC-20 amount or an ERC-721 NFT) and setting a ticket price, a ticket cap, and a duration. Entrants buy tickets in a stablecoin. When the raffle expires, a draw is requested from a verifiable randomness source and the winner is picked from the ticket ranges.

The draw is the easy part. A randomness provider can stall, a winner can be blacklisted, a prize token can pause, and the contract is built so that none of those end with the prize stuck on it.

• Two randomness backends, one accounting engine. Robinhood Chain has no Chainlink VRF deployment, so it runs Quiver with a resolver-gated draw; BSC runs Chainlink VRF v2.5 through a permissionless upkeep.
• Resolution is driven by keepers I operate, not by Chainlink Automation. On Robinhood Chain that is a Node service with two cron jobs (resolve, then settle from the randomness callback); on BSC it is a shell-driven loop.
• Every draw request folds in a fresh salt, so a colluding randomness provider can stall a raffle but cannot grind for a winner it likes.
• Payouts are push-with-escrow-fallback: if a transfer fails, the funds move to a claimable balance instead of reverting the settlement and freezing the raffle.
• Cancelled raffles refund with O(1) pull accounting, and an underfilled raffle returns the prize to the host while still drawing the ticket pool, so nobody's money is stranded.

TokenForge — security token tooling

Issuance tooling for Indonesian real-world-asset issuers. It implements the Solana Security Token Standard (SSTS, the Halborn and Securitize design) with sRFC37-compliant transfer hooks, so a token can carry regulatory rules like transfer restrictions and holder eligibility at the token layer instead of in an off-chain database.

The repository is private while it is used with clients. The public product site shows what it does.