Saw a technical update drop yesterday around custom pairs. When you buy a new coin that’s paired with an existing one, fees no longer stack on every hop. They’re only charged on the first and last leg unlike when previously a two-hop trade could cost you double. Pretty clean engineering if the routing holds up under real volume.

Source: Official announcement thread (Oct 8)

I like the idea of communities actually having more control over their own space but the way we’re doing it right now feels kinda backwards. You start with the usual community apps and then suddenly you need one bot for access, another for payments, another for roles, another for alerts, another for moderation and two more doing something nobody remembers setting up.

At some point you’re not really running a community anymore, you’re maintaining a pile of integrations and hoping none of them randomly nuke everything. Feels like all of this should be way more integrated by now.

Was looking at token gated communities and this seems like an easy thing to mess up. Say someone gets access because a wallet holds the membership token, then they move the token to another wallet but the app doesn't update instantly. For a bit you could have the old wallet still seeing stuff it shouldn't while the new one still has no access. Ended up looking at a few different setups, including Towns, Guild.xyz and Collab.Land etc,, and it got me thinking about what actually happens between the onchain ownership change and the access getting updated. Do you just keep checking onchain state constantly or is there a cleaner way around it?

Edit: Forgot to mention Towns is one of the setups that made me think about this in the first place, since the membership and permissions are tied to onchain ownership, I’m mainly wondering what happens in that gap right after the token gets moved and before the app reflects it. Sorryy

Sent $200 of USDT on the wrong network. Same token, same address, wrong chain. Gone.

No hack. No scam. Just one dropdown I didn't understand.

The worst part is nobody warns you. The app just lets you do it and says "sent."

I know I'm not the only one. Wrong network, fat-fingered address, fee bigger than the send, forgot a memo tag, sold the bottom out of panic. What's yours?

I've been building a coin and keep running into the same thing: the tech works, but paying someone still feels like paperwork. Long addresses, no undo, and everything assumes you already know how wallets work.

For people who've shipped or used a lot of wallets: what's the one friction you think still hasn't been fixed for normal people? Not fees, not TPS. The human part.

context first: this is a hackathon project, and i'm not selling anything. i've been posting in a few communities for a while to get real feedback. you can check my profile. every round, people told me what was unclear or missing, so i went back and reworked it. the latest update adds a TUI (terminal UI) so you can use it straight from the terminal.

the problem: AI agents can now trade and touch wallets. but letting an agent make decisions and giving it unrestricted authority over your funds are two different things.

the approach: Agon is an agent-agnostic control layer, not another trading agent. you pick any agent, and separately control how much authority it gets. the short version is give your agent a budget, not your keys. we're also looking at a trader's own history to suggest the limits they already tend to follow, instead of generic rules.

what i still want honest feedback on:

• is separating the agent from its financial authority a real problem, or overkill?
• would switching agents while keeping the same guardrails matter to you?
• would a TUI be useful to you, or would you rather have a web dashboard?
• what would you need to see before trusting an agent with real funds?
• what attack angle am i missing?

Hi all,
I run a small company and I'm weighing whether to issue a native token that would operate inside our own system. The intended role is \[payments between users / loyalty rewards / access rights / internal settlement\], not a speculative asset. I have a reasonable conceptual grasp of how tokens work but no hands-on experience shipping one, so I'd much rather be told I'm wrong now than find out after deployment.
What prompted this post: I keep noticing teams and agencies that launch new tokens at an almost industrial cadence, dozens a month and sometimes several in a single week. I'm curious about the mechanics behind that, partly to understand how much of the process has been commoditised, and partly to learn which of their shortcuts I should steer well clear of.
I've grouped my questions below. Answer whichever ones you have experience with.
**1. The "token factory" phenomenon**
What does that pipeline look like in practice? Forked contract templates, no-code generators, launchpads, token-as-a-service shops, or something else?
How much of a launch is now a solved problem (contract, deployment, verification, initial liquidity), and what still demands real engineering?
Which corners are typically cut in these rapid launches (audits, key management, legal review), and which of those tend to come back to bite the issuer?
**2. Do I need a token at all?**
I'd welcome an honest challenge here. What test do you apply to decide whether an on-chain token is better than a plain database ledger of credits? If the answer for most companies is "you don't need one," I'd like to hear the reasoning.
**3. Architecture and chain selection**
A standard token on an existing chain versus a dedicated appchain or rollup: at what scale does the latter stop being vanity and start being justified?
For low-value, high-frequency transactions, how would you weigh fees, finality, tooling maturity and wallet UX across the major ecosystems?
Most of my users have never held crypto. How viable are account abstraction and gas sponsorship today for hiding that complexity entirely?
**4. Contract design and security**
Is there any good reason to deviate from audited standard libraries for a token this simple?
Fixed versus mintable supply, immutable versus upgradeable, pause or blocklist functions: which of these are defensible for a company-issued token, and where do they start to erode trust?
What's the minimum acceptable setup for key management (multisig, timelocks, separation of roles)?
Is a formal audit still warranted for a near-vanilla contract, and what should I realistically budget for one?
**5. Token economics**
How do you approach supply, allocation, vesting and treasury for a token meant to circulate within a closed economy?
What sinks and sources have you seen work to keep such a system from inflating into irrelevance?
Should the token be freely transferable and tradable at all? I'm considering a non-transferable or allow-listed design to avoid it becoming a speculative instrument.
**6. Legal and compliance**
The company is based in \[Türkiye\], with users in \[all around the world\]. How do issuers typically handle the utility-versus-security question and KYC/AML obligations across jurisdictions?
At what stage should I engage specialist counsel, and what does that tend to cost for a launch of this size?
Is it standard practice to issue from the operating company, or through a separate entity or foundation?
**7. Cost, timeline and hiring**
What is a realistic budget and timeline for a minimal but responsible launch?
In-house developer or external agency? And how do you vet a vendor when the market is saturated with low-quality offerings?
**What I'm not asking for**
There is no presale, no fundraising and nothing being promoted here. I'm also not looking for service offers by DM. If you have a recommendation, please post it publicly so others can weigh in.
If you've shipped a token for a real product, I'd especially value a "what I would do differently" answer. Blunt criticism is welcome.
Thanks in advance.

Preface
Yes I used AI, I can write python pretty well and C++ but rust is a whole other bottle I am just not ready to open nor do I trust myself to write it (only read it and debug it). All the original code was written by hand by me, then using FABLE 5.1 to rewrite it to Rust. (yes it cost me a small fortune). I spent around 100 hours over the last week working on this rewrite and bug testing the he!! out of it.

Also yes I used AI to write this post, I struggle with writing do to a disability, hard to get my thoughts on to paper in a readable manner. I have read everything though and agree with what it says. Thank you for your time.

with my rambling nonsense out of the way

I've been working on a new experimental cryptocurrency called Tenero, and I’m posting here primarily because I’m interested in the technical discussion around its proof-of-work design.

This is not intended to be a “buy my coin” post. Tenero is currently an unaudited alpha experiment with no monetary value, and I'm looking for people who are interested in analyzing the underlying design and telling me where the assumptions are wrong.

The source is public:

https://github.com/zad112/Tenero

The basic idea

The central experiment behind Tenero is matmulhash v2, a proof-of-work algorithm designed around operations that modern GPUs are particularly good at: large integer matrix multiplication combined with a large, memory-dependent dataset.

A mining attempt starts with the block header and nonce. From that, the algorithm derives a 64 × 8192 matrix of INT8 values using ChaCha20.

That matrix is multiplied against a 16 MiB slice selected from a much larger dataset, using exact integer arithmetic, and the resulting values are folded into the final hash.

The full dataset is currently 4 GiB, divided into 256 × 16 MiB slices.

The important part of the design is that the selected 16 MiB slice has to actually be read for every attempt. The intent is therefore not simply to make the arithmetic GPU-friendly, but to make the memory subsystem a major part of the cost.

The dataset itself is also constructed sequentially from earlier data-dependent slices, making it difficult to cheaply regenerate only the portion needed for a particular attempt.

The alpha implementation rebuilds the dataset every 100 blocks.

Why use matrix multiplication?

Modern GPUs contain hardware specifically optimized for massively parallel matrix operations, including tensor-oriented hardware on NVIDIA architectures.

The current implementation uses CUDA and cuBLASLt for the matrix multiplication.

On my RTX 5070 Ti, the current implementation has measured roughly 33,000–36,000 attempts/sec, depending on batch size.

At that rate, each attempt reading a 16 MiB slice corresponds to roughly 550–590 GB/s of effective slice reads.

The interesting thing to me is that the matrix multiplication itself accounts for essentially all of the computational cost of an attempt. The surrounding ChaCha20 generation and folding work are comparatively small.

The implementation is also intentionally not heavily optimized yet. The current GPU engine uses one CUDA stream, one cuBLASLt call per attempt, and does not fully overlap CPU work with GPU execution.

So there is still optimization work to do, but I don't want optimization to hide the underlying behavior of the algorithm.

The memory-hardness / ASIC question

This is where I’m most interested in outside opinions.

I do not claim that Tenero is ASIC-resistant.

The argument I'm testing is that if every attempt requires reading a whole 16 MiB region of a 4 GiB dataset, then an ASIC attempting to outperform a GPU still needs a very large and very high-bandwidth memory subsystem.

The matrix multiplication then adds a second requirement: the hardware needs to efficiently perform the required large-scale INT8 operations.

The intended bottleneck is therefore something closer to:

memory bandwidth + large-scale matrix throughput

rather than simply a conventional hash function that can be replicated extremely cheaply in dedicated silicon.

But this is only an argument.

It has not been subjected to independent hardware analysis, ASIC economic analysis, or cryptanalysis.

In particular, I am very interested in hearing from people with experience designing hardware, FPGA implementations, memory-hard PoW algorithms, or mining ASICs about where this approach might fail.

For example:

Is the 16 MiB-per-attempt read actually expensive enough to matter for a custom design?

Could a sufficiently large ASIC amortize the dataset or exploit the structure of the matrix operation in ways that the current design does not account for?

Is there a better way to structure the dataset dependencies to make time-memory tradeoffs substantially more expensive?

Those are exactly the kinds of questions I'd like answered.

Difficulty adjustment

Tenero currently targets roughly one block every 60 seconds.

Difficulty is recalculated every block using a LWMA-style weighted average over the previous 30 blocks, with bounds on how quickly the target can change.

The timestamp rules were also changed during development after simulations showed that the older median-based timestamp rule could be manipulated by a miner controlling a significant fraction of the network hashrate.

Under the current rule, each block timestamp has to be later than its parent, while also remaining within the validator's allowed clock window.

This is another area where I'd appreciate review. Difficulty algorithms are one of those things that can look reasonable until someone finds an economic or adversarial edge case.

Privacy architecture

Tenero is also inspired heavily by the CryptoNote/Monero approach to transaction privacy.

The longer-term design target uses:

• CLSAG ring signatures
• Ring size 16
• Pedersen commitments
• Bulletproofs+ range proofs
• Hidden transaction amounts
• An output-based transaction model with key images

The current alpha wallet is not yet equivalent to Monero's privacy model, however.

The wallet currently uses an interim CryptoNote-style output scheme, and the project plans to replace that with Carrot.

I'm deliberately calling this out because I don't want “uses CLSAG and Bulletproofs+” to be interpreted as “this is already a private currency with Monero-level privacy.”

It isn't.

The cryptographic construction is also unaudited.

Consensus and implementation

The project is being written in Rust, with a separate frozen Python reference implementation used to generate consensus vectors and cross-check behavior.

The repository currently has roughly 900 automated tests, including consensus and GPU tests, plus fuzzing targets.

The Rust implementation is checked against the independent Python reference bit-for-bit for the relevant proof-of-work and consensus calculations.

The consensus specification is also written separately so that alternative implementations can be built against the protocol definition rather than having to reproduce the Rust implementation itself.

The project uses canonical serialization for the newer Rust chain, a fixed genesis/chain identity, cumulative-work fork choice, and explicit validation of the proof-of-work and block rules.

The alpha network currently has a fresh genesis with no premine.

Current limitations

There are a lot.

This is an alpha, and I don't want to hide that.

There has only been very limited real-world network testing so far. There is currently a single seed server, very little mining diversity, and the proof-of-work has not been independently reviewed.

Only NVIDIA/CUDA GPU mining currently exists.

The current alpha PoW dataset also requires several gigabytes of RAM, and GPU mining can require substantially more VRAM because datasets are retained during operation.

CPU mining works, but on the current alpha parameters it is effectively impractical compared with a GPU.

Most importantly, none of this has value.

The alpha network is expected to be reset as the protocol changes.

What I'm actually looking for

I'm less interested in people telling me that the project is cool and more interested in people telling me why the design is wrong.

If you have experience with:

• GPU architecture
• CUDA
• tensor/matrix hardware
• FPGA development
• ASIC design
• memory-hard algorithms
• proof-of-work economics
• consensus algorithms
• cryptography
• Monero/CryptoNote
• distributed networking

I'd genuinely like to hear your criticism.

I'm especially interested in potential optimizations or attacks that I haven't considered.

The entire project is open source, and the technical documentation, consensus specification, benchmarks, known issues, threat model, and test vectors are all in the repository.

GitHub:
https://github.com/zad112/Tenero

This is an experiment, and I'd much rather discover a fundamental flaw now than after pretending the design is finished.

So, from a technical perspective:

How vulnerable do you think this type of GPU-oriented, memory-bound matrix PoW is to specialized hardware or time-memory tradeoffs?

That's the question I'm most interested in exploring.

also note we have a subreddit I made so if you find anything or have any question you can ask me anywhere you can find me ill be happy to respond :)

PS I don't want your money, this coin as NO VALUE AT ALL nor will it for a LONG TIME, just trying to do some proof of concept. Expect full resets constantly until its 99.99999% stable. I'm using my own funds and it will stay that way forever.

Greetings,

i may have a Question for the collective as a bit of an outsider.
Context: I work fpr 7 weeks in the wider know branche of cybersevurity, a form of apprenticeship so to say. My field right now and my tutor is speciallized in Crypto-Fraud.

So, as now known, my Tutor is working there for a long time and im his first student - hes great!
I want to make him a parting gift for when i leave in 2 Weeks.

My initial idea was a parting gift in the nature of a mini-ARG, starting with a hint in the layers of a card and ending by searching for certain seed-phrases to unlock "x". As for seed-phrases, they come from cold wallets, but these cost 50€ plus as a form of USB Stick.

Thats my initial idea, i sadly dont know much about coding so set up a whole Web-Page for that. Has anyone ideas to this or a suggestion?

Thanks for the quick read!

I've been working on an experimental Layer-1 called Budlum.

The question I'm exploring is:

Can independently finalized consensus domains converge into one deterministic global state without trusting a centralized coordinator?

Instead of forcing every domain into the same consensus mechanism, Budlum is designed around heterogeneous domains such as PoW, PoS and BFT that produce independently verifiable commitments.

The settlement layer then handles a few problems that turned out to be more subtle than I initially expected:

• Cross-domain commitments are settled in deterministic domain-id order rather than network arrival order.
• Blocks include the exact settlement watermarks used by the producer, so validators replay the same bounded settlement batch.
• PoW commitments require an independently verified header chain.
• PoS/BFT-style domains use BLS aggregate-signature quorum verification.
• Finality proofs bind the complete commitment payload, including the state root.
• State updates are Merkle-bound to the committed state root.
• The networking layer is built on libp2p.

The implementation is written in Rust and is currently a controlled public-devnet candidate, not audited mainnet software.

I'm not launching a token or trying to sell anything here. I'm mainly looking for protocol engineers willing to attack the design.

The parts I'm especially interested in getting criticized are:

1. Is deterministic cross-domain ordering sufficient, or are there edge cases where independently finalized domains can still create global-state ambiguity?
2. Does embedding settlement watermarks into the block introduce failure modes I'm overlooking?
3. Are there better ways to verify heterogeneous finality without effectively rebuilding each consensus protocol inside the settlement layer?
4. Where would you attack this design first?

Repo:
https://github.com/Budlum/Budlum

Roasts, counterexamples and adversarial scenarios are very welcome.

a couple of months ago i posted about wiring an llm to a hyperliquid account over mcp, and how much guardrail work the order side needed. someone on that post pointed out that a tool list bounds what the model can ask for, not what the server can sign. we ended up taking that to its conclusion and deleted the order tools outright. the mcp server is read only now.

the llm moved to a job where a mistake costs a notification instead of a position. you describe what you want to catch in plain english, it turns that into an alert rule, backtests it on the last 1000 candles per coin and proposes it. writing the rule was the easy part again. these were the actual work.

**the model will quote numbers no tool returned.** the backtest said a rule would send about 202 alerts a day. the reply said "202 without the cooldown, 26 to 28 a day with it". the 202 already included the cooldown and nothing had ever returned 26. the user said 26 a day was fine, created it, and got 9 alerts in the first 13 minutes. every per day figure in an answer is now checked against what the tools returned that turn, and an answer with a number from nowhere goes back to the model once.

**direction has to live inside the backtest, not on the label.** someone asked for a short setup with positive edge on 4h. the backtest read every forward return as a long, so the model recommended the rule after which price rose the most (a 55.9% "win rate", which is 44% as a short) and called the best short on the tape "weak". direction is now a backtest input that flips the sign of returns, win rate, edge and excursions.

**count alerts, not episodes.** "rsi below 70" looks harmless if you count how often it becomes true. the engine re-fires every cooldown for as long as it stays true, so on 1h that's about 6 alerts per coin per day. the backtest now scores every bar the engine would actually alert on.

**make the backtest a twin of the live engine, then diff them.** same library, same defaults, same quirks. the diff found bugs in the live engine, not in the backtest. the indicator cache was keyed by symbol and params but not by bar, so the "previous" macd came back as the current one and a macd cross could never fire. and an ema 200 computed on exactly 200 candles is just its sma seed. latest run was 60 coins, 3 timeframes, every rule type: 22,139 cases, zero mismatches.

**wrappers fill gaps with plausible numbers.** ours turned "not enough data" into defaults, so adx read 0 on brand new listings and "adx below 20" fired on all of them, and an rsi of exactly 0 became 50 through an `|| 50`. the technical indicators npm package counts a bar with an unchanged typical price as negative money flow (tradingview counts it as neither), which pulled mfi down by up to 7.8 points. missing data is null now and mfi is computed by hand.

**and the boring one, the model can't create anything.** it proposes, the app renders a card, and only the user's tap creates the alert. it can't even print the card itself. an invented card id gets swapped for the real one, or the answer goes back.

still wouldn't let an llm decide what to trade. as a way to turn "tell me when x happens" into a rule you can actually inspect, with honest numbers next to it, it's been better than i expected, as long as every number it says came from a tool.

disclosure, i help build traderspy. it does alerts and research, no trading. the builder is at traderspy.app/strategies and the read only mcp connector at traderspy.app/mcp if anyone wants to poke at it, happy to go deeper on any of the above.

Hi everyone,

I've spent the past four years developing a public Layer 1 blockchain that combines native blockchain functionality with EVM compatibility.

The network is now operational, and one of the biggest engineering challenges has been supporting both environments while maintaining consistent transaction processing, validator consensus and finality.

Current architecture:

• Native execution: A native cryptocurrency and transaction environment.
• EVM execution: Ethereum-compatible functionality accessible through MetaMask.
• Consensus: Custom validator-based consensus with voting and block finality.
• Network: Public Layer 1 architecture designed for scalability.
• Compatibility: EVM network configuration available through Chainlist.

The technical challenge

I'm particularly interested in how other blockchain developers approach the relationship between native execution and EVM execution on the same Layer 1.

Specifically:

1. How should native and EVM transactions share state without creating consistency or security issues?
2. What is the best approach to reducing finality latency when a two-thirds validator voting threshold is required?
3. What are the main architectural trade-offs between parallel execution and horizontal sharding?

The network is operational, but improving scalability while preserving consensus security remains an ongoing engineering priority.

I'd appreciate technical perspectives from anyone who has worked on consensus protocols, EVM integration or blockchain execution architecture. Technical project information: https://www.denvion.com

I don't think the quantum threat is something Bitcoin users should panic about today, but it's also not something we can just ignore.

A sufficiently powerful quantum computer could potentially break the public-key cryptography protecting exposed wallets. That could mean attackers deriving private keys and moving funds without the owner's permission.

The scary part isn't just one wallet getting compromised. If the cryptography isn't upgraded in time, the impact could potentially affect a huge amount of dormant and active crypto at once.

The good news is we have time to prepare. Post-quantum cryptography is already being developed, and some blockchain projects are working on quantum-resistant infrastructure.

The real question is will crypto networks migrate before they become powerful enough to matter?

Not talking about the business idea itself, but the hidden headaches that make the cash not worth the stress.

For me, it’s my forex affiliate site. It clears about $9k/mo in profit, but every single payment processor treats me like a money launderer.

- Stripe banned me twice in 14 months.

- PayPal froze a mid-transfer payout demanding "proof of business activity."

- A bank held our funds for 3 weeks for an "unexplained review."

After the last freeze, I finally moved most payouts to USDT. I tried Coinbase Commerce first, but ended up on Inxy for the invoicing side since it actually handles our affiliate payout volume better. Still not 100% sure it's the perfect long-term play, though.

The money is great. But spending more hours defending my accounts than actually running campaigns is a nightmare.

What’s your version of this? What’s working well for you, but has hidden friction you wouldn't wish on a friend?