❌

Reading view

There are new articles available, click to refresh the page.
↗️

AI Could Be Bitcoin’s Next Onboarding Engine, Nakamoto CEO Says

✇Bitcoin Magazine
By: Mathew Di Salvo

Bitcoin Magazine

AI Could Be Bitcoin’s Next Onboarding Engine, Nakamoto CEO Says

Artificial intelligence may turn out to be an unexpected driver of Bitcoin adoption, according to Nakamoto Holdings CEO and Chairman David Bailey.

In a discussion hosted by investment bank TD Cowen, Bailey’s argument was that the friction getting people on board with Bitcoin has always been the interface — and not the asset. 

Wallets, addresses, private keys, and the general onboarding process have kept mainstream users at arm’s length for well over a decade, he argued. AI-powered tools could abstract that complexity away and make the asset far easier for ordinary individuals and institutions to actually use.

TD Cowen analyst Lance Vitanza, who published a note on the conversation, described the idea as speculative but worth attention, noting that it moves the adoption conversation beyond the familiar territory of monetary policy, regulation, and institutional flows.

Bailey added that institutional adoption of Bitcoin has barely begun: spot ETFs, corporate treasury programs, and sovereign-level interest have transformed access over the past year — more, in Bailey’s estimation, than the previous decade-plus combined. He argued the addressable opportunity ahead remains considerably larger than what has been captured.

Asked whether Bitcoin is reshaping traditional finance or the reverse, Bailey came down firmly on the former. Institutions, governments, and public companies are participating at scale, but the asset’s underlying properties have not bent to accommodate them. The adaptation, he argued, is running one direction — toward an asset whose rules none of those players control.

With direct exposure now widely available through ETFs, Bailey downplayed the usual distinction between “treasury company” and “operating company.” The question that matters, he said, is whether a business can grow the amount of Bitcoin it holds per share over time — a test of capital allocation and execution rather than balance-sheet size.

Nakamoto itself has moved in that direction, positioning as an integrated Bitcoin platform spanning media, conferences, education, asset management, advisory work, and treasury operations. Vitanza called it one of the more differentiated strategies among Bitcoin-native public companies, while noting the approach has yet to prove itself.

TD Cowen rates Nakamoto Holdings (NASDAQ: NAKA) Buy. TD Securities discloses that it makes a market in the stock.

Bitcoin Magazine is published by BTC Inc, a subsidiary of Nakamoto Inc. (NASDAQ: NAKA)

This post AI Could Be Bitcoin’s Next Onboarding Engine, Nakamoto CEO Says first appeared on Bitcoin Magazine and is written by Mathew Di Salvo.

↗️

Mallers: Bitcoin and AI Could Give Humans Back Their Time

✇Bitcoin Magazine
By: Mathew Di Salvo

Bitcoin Magazine

Mallers: Bitcoin and AI Could Give Humans Back Their Time

Bitcoin — along with artificial intelligence — could help humans get their time back to create again, according to Strike CEO Jack Mallers. 

The reason: hard money doesn’t rob people of their time and energy and truly rewards people time and energy well spent, Mallers argued on Bitcoin Magazine’s debut TV show on Monday. 

“Money broadly is our time and energy in an abstracted form — it is the market good that represents the effort, the labor,” Mallers said. 

“If the money is bad, it’s very destructive to our time and energy: It robs us of our time and energy. You have to work longer and harder to get a house; you have to work longer and harder to get a vacation. You have to work longer and harder to have hours to pursue your artistic interests.”

“And if the money is good, it actually gives you and rewards back time and energy,” he continued, adding that Bitcoin and AI could free humans from the “drudgery” of bad money.

Mallers went on to cite the example of the creators of the airplane, the Wright brothers, who came up with their invention when the U.S. was on a gold standard. 

Mallers’ comments come following Bitcoin’s best run in years. Bitcoin gained about 25% in August, its strongest month of 2026 and its first positive August since 2021, closing the month near $78,000.

LIVE: Bitcoin, Macro, Clarity Act Look-Ahead | BMTV Sep. 14, 2026https://t.co/iAxbKgj2Op

— Bitcoin Magazine (@BitcoinMagazine) September 14, 2026

The run followed Treasury Secretary Scott Bessent’s move to expand long-dated bond buybacks, which pulled yields down and triggered billions in short liquidations.

Since the news, the so-called debasement trade has been back in the headlines again: when traders buy assets like gold or bitcoin to hedge against a currency losing its value. 

The dollar slid on the Treasury buyback news and an announcement the same week that U.S. debt had hit the $40 trillion mark. 

Speaking about the state of the U.S. economy, Mallers added: “This level of debt is unsustainable, so when people debate, oh well, what if they hike rates? What if they cut rates? It doesn’t matter: it’s all inflationary and it’s all untenable.”

Data on Friday revealed that the consumer price index, excluding food and energy, climbed 0.3% in August from a month earlier — higher than expected.  

The U.S. is currently in the grips of an affordability crisis, and it’s widely expected that the Federal Reserve will raise interest rates this week to tame inflation as oil prices have surged. 

This post Mallers: Bitcoin and AI Could Give Humans Back Their Time first appeared on Bitcoin Magazine and is written by Mathew Di Salvo.

💾

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
↗️

Programming Math for Vibe Coders.

✇Coinmonks
By: Kwame Bryan

Programming Math for Vibe Coders Mojo Edition

Introduction

Leslie Lamport has long argued that programming is not simply coding.

Before writing code, we first need to think precisely about what the program should do and how it should behave.

That distinction matters even more in the age of AI-assisted programming.

A coding agent can generate Mojo, Python, Rust, Solidity, JavaScript, or almost any other language in seconds.

But it still needs a precise description of the problem it should solve.

This is where mathematics becomes incredibly useful.

Mathematics gives us a compact language for expressing relationships, constraints, quantities, state, and behaviour without committing ourselves to a particular programming language.

For many learners — and yes, vibe coders, I’m calling you out here — the difficult part isn’t necessarily understanding code.

It’s learning how to move between:

Idea → Mathematical Model → Algorithm → Code

In this article, we’ll explore that process using Mojo 🔥, a statically typed systems programming language with Python-like syntax.

The mathematical ideas themselves are independent of Mojo.

You can translate them into almost any programming language.

That is one of the beautiful things about approaching software mathematically:

The model survives even when the implementation language changes.

Knowledge Transfer Guide

Translating Math to Mojo: Cheat Sheet

Summation

∑ → accumulation using a loop and +=

Product

∏ → repeated multiplication using a loop and *=

Mathematical bounds

i = 1 … n → range(1, n + 1)

Indexed values

xᵢ → values[i]

Functions

f(x) → def f(x: Type) -> Type:

Real numbers

ℝ → Float64

Integers

ℤ → Int

Sequences

x₁, x₂, …, xₙ → List[T]

Infinite sums

∞ → approximate using a finite number of terms

One important detail:

Mathematical ranges are commonly inclusive.

For example:

1 ≤ k ≤ n

In Mojo, range() follows Python-style half-open ranges.

So:

range(1, n + 1)

represents:

1, 2, 3, …, n

This small difference is exactly the kind of bug mathematical thinking can help us catch.

Factorial: From ∏ to a Loop

Mathematical Definition

n! = ∏ from k = 1 to n of k

In expanded form:

n! = 1 × 2 × 3 × … × n

Mojo Implementation

def factorial(n: Int) raises -> Int:
    if n < 0:
        raise Error("Factorial is not defined for negative numbers.")
    var result: Int = 1
    for k in range(1, n + 1):
        result *= k
    return result

Explanation

The mathematical expression:

∏ from k = 1 to n of k

contains three pieces of information.

The variable:

k

becomes our loop variable.

The bounds:

1 ≤ k ≤ n

become:

range(1, n + 1)

And the product:

∏

becomes:

result *= k

Something subtle is also happening here.

We initialise:

var result: Int = 1

Why 1?

Because 1 is the identity element for multiplication:

1 × x = x

For addition, the identity element is 0:

0 + x = x

So a summation accumulator normally starts at 0.

For multiplication:

1 × x = x

So a product accumulator starts at 1.

Our implementation also correctly handles:

0! = 1

When n = 0, the loop executes zero times and result remains 1.

This gives us a useful programming principle:

The initial value of an accumulator often comes directly from the mathematics of the operation.

A Mojo-Specific Observation

Unlike Python integers, Mojo’s standard Int integers represent a finite machine integer.

That means sufficiently large factorials will eventually exceed what the type can represent.

The mathematics hasn’t changed.

The representation has.

This gives us another important rule:

Mathematical correctness and representation correctness are not always the same thing.

Approximating e Using an Infinite Series

Mathematical Definition

Euler’s number can be defined as:

e = ∑ from n = 0 to ∞ of 1 / n!

Expanded:

e = 1 + 1 + 1/2! + 1/3! + 1/4! + …

A computer cannot normally execute an infinite number of operations.

So instead we calculate a finite approximation:

e ≈ ∑ from n = 0 to N − 1 of 1 / n!

Mojo Implementation

def approximate_e(terms: Int = 12) raises -> Float64:
    if terms < 1:
        raise Error("terms must be at least 1")
    var total: Float64 = 1.0
    var term: Float64 = 1.0
    for n in range(1, terms):
        term /= Float64(n)
        total += term
    return total

Explanation

We could calculate every factorial independently.

But the mathematics gives us a better algorithm.

We know:

n! = n × (n − 1)!

Therefore:

1 / n! = (1 / n) × (1 / (n − 1)!)

This means you can calculate each new term from the previous one.

Instead of repeatedly calculating:

1!, 2!, 3!, 4!, …

we simply write:

term /= Float64(n)

Then accumulate it:

total += term

This is an important lesson:

Mathematics does not merely describe the answer. It can reveal a better algorithm.

Calculating an Average

Mathematical Definition

For values:

x₁, x₂, …, xₙ

the arithmetic mean is:

x̄ = (1 / n) × ∑ from i = 1 to n of xᵢ

In plain language:

average = sum of all values/number of values

Mojo Implementation

def average(values: List[Float64]) raises -> Float64:
    if len(values) == 0:
        raise Error("Average is undefined for an empty collection.")
var total: Float64 = 0.0
for i in range(len(values)):
    total += values[i]
return total / Float64(len(values))

Explanation

The mathematical summation:

∑ xᵢ

becomes an accumulator:

var total: Float64 = 0.0

followed by:

for i in range(len(values)):
    total += values[i]

Then:

1 / n

becomes:

total / Float64(len(values))

Notice the explicit conversion:

Float64(len(values))

len(values) gives us an integer.

Our calculation produces a floating-point result.

The code therefore states the numerical representation explicitly.

This is one place where Mojo’s type system makes mathematical intent more visible.

The Empty Collection Problem

Suppose:

n = 0

Our formula would require division by zero.

So the average of an empty collection is undefined.

This would therefore be misleading:

if len(values) == 0:
    return 0.0

Zero is not the average of an empty collection.

There simply is no average.

So instead we use:

raise Error("Average is undefined for an empty collection.")

Another useful rule follows:

Edge cases should follow the mathematical definition, not whatever value is convenient for the implementation.

Computing Variance

Variance measures how far values tend to spread from their mean.

First calculate the mean:

μ = (1 / n) × ∑ from i = 1 to n of xᵢ

Then calculate the population variance:

σ² = (1 / n) × ∑ from i = 1 to n of (xᵢ − μ)²

Mojo Implementation

def variance(values: List[Float64]) raises -> Float64:
    if len(values) == 0:
        raise Error("Variance is undefined for an empty collection.")
    var total: Float64 = 0.0
    for i in range(len(values)):
        total += values[i]
    var mean = total / Float64(len(values))
    var squared_difference_sum: Float64 = 0.0
    for i in range(len(values)):
        var difference = values[i] - mean
        squared_difference_sum += difference * difference
    return squared_difference_sum / Float64(len(values))

Translating the Equation

Take this part:

(xᵢ − μ)²

The current value:

xᵢ

becomes:

values[i]

Subtract the mean:

xᵢ − μ

becomes:

var difference = values[i] - mean

Square the difference:

(xᵢ − μ)²

becomes:

difference * difference

The summation:

∑ (xᵢ − μ)²

becomes:

squared_difference_sum += difference * difference

And finally divide by n:

squared_difference_sum / Float64(len(values))

Population Variance vs Sample Variance

Small mathematical differences matter.

Population variance uses:

σ² = (1 / n) × ∑(xᵢ − μ)²

Sample variance usually uses:

s² = (1 / (n − 1)) × ∑(xᵢ − x̄)²

The implementation difference may appear tiny.

Population:

Float64(len(values))

Sample:

Float64(len(values) - 1)

But mathematically these represent different quantities.

This is exactly why specification matters.

A coding agent told:

Calculate variance.

has to make assumptions.

A coding agent given:

σ² = (1 / n) × ∑(xᵢ − μ)²

has much less room to guess.

The Bigger Lesson

At first these examples may look simple.

∏ becomes multiplication inside a loop.

∑ becomes accumulation.

xᵢ becomes an indexed value.

f(x) becomes a function.

But a more important idea underlies all of this.

We are learning to move through four layers:

Problem → Mathematical Model → Algorithm → Code

Most vibe coding jumps directly from:

Problem → AI-Generated Code

That works surprisingly often.

Until it doesn’t.

The problem is ambiguity.

Natural language might say:

Execute when everyone agrees.

We can express that more precisely.

Let:

P = {p₁, p₂, …, pₙ}

represent all participants.

Let:

A ⊆ P

represent the participants who have accepted.

Then we can define:

Ready(I) ⇔ A = P

In plain language:

The intent is ready exactly when the set of accepting participants equals the set of required participants.

Now add time:

Ready(I) ⇔ A = P AND t < expiry(I)

Now we have expressed two requirements:

  1. Everyone must accept.
  2. The intent must not have expired.

An AI coding agent can translate that into Mojo, Solidity, Rust, Python, TypeScript, or another language.

The implementation language can change.

The specification remains.

From Vibe Coding to Specification

This suggests a different way of thinking about AI-assisted software development.

Instead of:

Natural Language → Generated Code

we can use:

Natural Language → Mathematical Intent → Specification → Generated Code → Tests

The goal isn’t necessarily for every programmer to become a mathematician.

The goal is to understand enough mathematical language to describe software behaviour precisely.

Because the future skill may not be memorising every programming language’s syntax.

It may be something more fundamental:

Learning to express intent precisely enough that humans, machines, and proofs agree on what the program is supposed to do.

Programming Math for Vibe Coders. was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

❌