Baron

BILA is live on NEAR testnet. An owner funds a treasury and sets the limits. The agent can only ask to spend. A contract on NEAR approves or blocks every request, so the AI model never holds the money. Thread below on how we built it.👇👇👇

The cheapest way to fill a Discord is also the fastest way to empty it. A quest campaign can bring in thousands of participants in a week, and almost none of them will ever use the product. That's what the reward was built to do. When the only thing on offer is a payout, the people who show up are the ones who are good at collecting payouts. They'll follow every account, join every chat and finish every task, because that's the job they signed up for. When the rewards stop, they go. Here's why this keeps happening. ◆ The reward picks your audience. Whatever you offer decides who answers. Offer money for clicks and you get people who click for money. Offer something that only makes sense if you use the product, and you get people who might actually use it. A campaign is a filter, and most teams set it to the wrong setting. ◆ Easy tasks attract easy exits. Follow, retweet, join the Discord. Anyone can do that in two minutes without knowing what you build. A task that costs nothing to complete tells you nothing about the person completing it. ◆ You're counting the wrong finish line. Tasks done, wallets connected, members joined. All of it counts activity. None of it tells you who's still around on day eight, once the rewards are gone. If you're about to run one, here's what I'd change. Tie the first task to the product. Make it something only a real user would bother doing, like using a feature, finishing a setup, or answering a question about what they found. Reward the second visit, not the first. Pay for the behavior that shows someone stayed. Judge the campaign two weeks after it ends, not on its last day. The number that matters is how many people are still there when nobody is paying them to be. Pay people to use the product and some of them stay. Pay people to make noise and the noise leaves with the budget.

GM CT and happy Taco Tuesday. Deal wondrously.

The first thing I do on a new project has nothing to do with marketing. I audit it. Any project I'm thinking about joining gets a full audit before I agree to anything. I go through it looking for everything that needs my attention, because I never want to be the person saying "I didn't know" a few weeks in. Once the audit is done, the next question is the team. If the project already has one, I join it and start working. If it doesn't, I bring in my own team, depending on what we agree in the terms, so we build it together from the start. Then comes the budget. I draft the marketing budget myself and send it to the founder before anything is spent. I want to know if the structure I've built is something he can actually work with. If it isn't, we find that out in a conversation and not in a bill. After that, we get to work, and everything lives in one place. The screenshots show what that looks like: one room for all the growth work with the approved audit pinned at the top, and the plan shared with the team so everyone agrees on the framework before the detail gets built. That's the whole order. Audit, team, budget, then work. If you're a founder hiring for growth, expect this from whoever you bring in. Someone who wants to see everything first and puts the money on paper before spending it is protecting your project as much as their own name. If you're a growth lead, try it on your next project. Audit before you agree, settle the team terms before you start, and get the budget in front of the founder before a single dollar moves. Do the slow part first, and the rest gets easier.

New week. Same energy, better execution. Let's go again. GM CT. Deal wondrously.

Finally decided to hit the gym today after 2+ months….. Let’s keep that body in shape again

Pay attention to things other people fail to see, that's how you win GM CT Deal wondrously.

It’s certain that I’ll win, I just pray I have the discipline to stick around while growth compounds….

We spent months building. We lost it in a few days. For months, the founder and I worked on one thing: getting the project ready. We structured it properly. We mapped out the right partners. We built an incentive model that gave something back to the community for being part of the journey. We pitched investors. The community chat kept growing, the follower count kept climbing, and it just kept getting better. Then the founder wanted to launch. The project wasn't ready for the influx of people a launch brings, and I knew it. I pushed the launch anyway. A few days in, everything dropped to zero. The community went quiet. The partners decided we weren't worth their commitment. The investors never came back with feedback. It cost us a lot. Backend development, trust, marketing spend that burned for nothing. And the hardest one, the edge we had with both our community and our investors. All of it from one irrational decision. Here's what I took from it, and it goes to founders and growth leads alike. Know exactly what you're trying to achieve before you launch. Write down what has to be true for the launch to go ahead: the product can handle the traffic, the team can support the people who show up, the partners are briefed, the community is ready. If those things aren't true, you don't launch. Decide where the line is before the pressure shows up. In the moment, momentum makes every deadline feel urgent. A line you drew in advance is much easier to hold. And remember that a failed project does nothing for the founder or the team. Everyone loses. This part is for the growth strategists. Being a growth strategist is more than a fancy way of saying marketer. You need a real say in what your founder proposes, and you need to use it. Otherwise you can end up where my founder and I did. Build with intention. Launch when the project is ready, and not a day before.

GM CT. Another day to deal wondrously.

Most people watch the launch. I watch what happens after it. I'm Baron, a Web3 growth strategist and marketer. I didn't choose this role by accident. I chose it because I can't stop asking one question: why does one project take off while another, with the same hype, goes quiet? There's always a system behind the answer. Who's actually in the room, what keeps people coming back, what the team does when the noise stops. Once you start seeing it, you can't unsee it. That's what I love most about this work. A lesson stays a lesson until I put it into a real project. Then it either holds or it doesn't, and I find out fast. I'll be sharing what I learn here, including the ones that cost me.

The week the rewards stop is the most honest week your project will ever have. I watched it happen to a project I once reached out to about a collaboration. What caught my attention was how much the founder was putting in to keep the project's audience around, all of it through incentives. For as long as the money kept flowing, the audience stayed. Then the incentives ended, and the audience left with them. It blew up in their face. I call this the Embarrassment Gate. It's Minute 7 of my 10 Minutes Framework, and it comes down to one question. If a user tried your product today, would they come back tomorrow without you reminding them? Take your time with that one. No hiding behind design. No hiding behind metrics. No hiding behind "we're still early." Here's why it matters. Retention that runs on incentives is borrowed. It looks like growth while you're paying for it, and the day you stop paying, you learn what you really had. A lot of teams find this out too late, and then they blame marketing, or the market. Here's how to tell where you stand. It passes when people return without a nudge. There's a reason to come back that has nothing to do with you pinging them. The product gives them something new each time, so one visit doesn't use it all up. It fails when users show up if reminded and drift off if not. Every visit feels like a one-time thing, and your best numbers sit right next to your biggest rewards. The one genuine way to fix this is to ask the users you already have. Give them a place to rate their experience, and you'll know what to prioritize. Then build the reason to return into the product itself. A loop, something that changes over time, an outcome that grows. Not another reminder. Here's the line I keep coming back to: if retention depends on you, it fails.

GM CT. Deal wondrously.

No free tokens. No dilution. Everyone enters the same way, through the same terms, at the same price. That's the whole point of a seed round done properly. $ONMX Seed Access is live. 👇

Nobody gets burned on the day they join a project. It happens a few weeks in, when you've already told everyone you're part of it, and you finally see what's behind the pitch. Behind every pitch is either a good narrative or a bad one, and either a good team or a bad one. And unfortunately, I've worked with projects that sell a good pitch but harbour a bad team. Most people join a project on a feeling. The founder was sharp on the call, the community looked alive, the roadmap had dates on it. All of it felt right, and that feeling is exactly what the project was selling you. That's why, before I put my name or my time on anything, I audit it. I want to know what I'm saying yes to. Here's what I check first. 1. What it actually does. Ask the team to explain the project to a stranger in one plain sentence. No buzzwords, nothing borrowed from other whitepapers. If the answer takes a paragraph, or changes depending on who you ask, the project doesn't know itself yet. And once you join, you're the one explaining it to everyone else. 2. Who's in the room. Don't count the community, read it. Scroll the chat for a week and watch who's talking. If people answer each other's questions and argue about the product, that's a community. If every message is a reaction under an announcement, you're looking at a crowd that showed up for the launch. A big number with a quiet room tells you more than any growth chart. 3. What got shipped. A roadmap is a wish with dates on it. Look at the last 90 days and see what actually went live, what was promised and quietly moved. Delays happen to everyone. What you want to see is a team that explains them. A team that ships small things steadily is worth more than one that announces big things once. 4. What happens when the founder steps away. Watch the project's quiet days. When the founder goes offline for a week, do the mods still answer questions, do updates still go out, does anyone else speak for the project? Strong projects keep moving without one person in the middle. If everything stops, you're not joining a team, you're joining one person's schedule. 5. How long they can last. Ask about runway like it's a normal question, because it is. How long can the team keep building if the market goes quiet for a year? Where does the money come from, and what is it paying for? A project that can't answer this plainly is either hiding something or hasn't thought about it, and you don't want to find out which from the inside. 6. How they treat the people who work for them. Talk to someone who's been there a while, like a mod, a designer or a past contributor. Ask how decisions get made, how people got paid, and how long it took. You'll hear it in how they answer, and in whether they hesitate. This one matters most to me, because a good pitch with a bad team is still a bad project. You don't need a spreadsheet for this. A couple of hours and honest answers to these six will tell you more than any deck. I'm not saying avoid projects. I'm saying walk in knowing what you're carrying, because once your name is on something, it travels with you.

Set your reminders….

Thank God for keeping things running smoothly. Web3 jobs did 😌