No token
No asset competing for user attention, no governance story, and no regulatory tail imported into your wallet.
For wallet teams
Give your users an inbox. Not a feature you have to maintain.
Post3 gives wallet users a verifiable mailbox at their wallet address. Projects can reach them with proof of identity while Post3 handles delivery, trust, and signature verification.
Example Wallet
0xd8dA...6045
Assets
Activity
Post3 Inbox
Settings
Post3 Inbox
Protocol treasury notice
verified domain + project wallet
Payment request
signer and payout wallet match
Trust proof
The inbox row can link into the proof panel Post3 shows in the hosted app.
No ads
Post3 does not monetize by selling wallet-user attention or training people to read sponsored mail.
No custody or nodes
Post3 routes messages and verifies signatures. It does not hold funds, run chain nodes, or write messages on-chain.
Why embed instead of build
Wallet messaging gets big fast, and closed inboxes do not compound.
Post3 is not asking you to adopt a chat app. It gives wallet teams the shared messaging layer they would otherwise spend quarters recreating.
Post3 already built the hard parts
SMTP ingress, MIME parsing, EIP-191, Ed25519, BIP-322 Bitcoin signature support, webhooks, dead letters, project identity, trust and abuse controls, delivery preferences, and digest scheduling.
Shared verification beats another closed inbox
Protocols will not integrate against every wallet one by one. An embedded Post3 inbox plugs your wallet into a shared verified-sender layer that other wallets and protocols can recognize.
It is not another roadmap quarter
Your team spends integration time, not platform-build time, and keeps focus on the wallet experience users already chose you for.
DNS TXT domain checks
Safe owner proof
name-service records
ERC-1271 wallet proof
BIP-322 wallet proof
contract ownership checks
webhook delivery headers
dead-letter replay
sender trust labels
What your users get
A mailbox that follows the wallet, not the app.
The user benefit is simple enough to explain inside the wallet UI.
A mailbox at their wallet address from day one.
Email from Gmail, Outlook, or any SMTP sender reaches [email protected].
Project announcements arrive with proof of who sent them.
Payment requests can be reviewed with signer and payout verification before wallet confirmation.
Phishing gets harder because legitimate senders can carry visible proof.
The mailbox follows the wallet across apps instead of being locked to one product.
What the wallet gets
A feature users understand, without importing Post3's business into yours.
The integration has to make business sense for a wallet, not only for Post3.
Ship in days to weeks
The work is integration and UI polish, not inventing an inbox, mail bridge, trust engine, and delivery system.
Increase wallet stickiness
A mailbox gives users a practical reason to keep your wallet as their daily wallet.
Keep user attention yours
Verified protocols can reach users through your product, and you decide how that engagement is presented.
No value capture conflict
Post3 takes no cut of value moving through the inbox.
No token program
No airdrop campaign, governance story, or asset competing for user attention.
No lock-in story to defend
The documented data model and export path give you an exit if the pilot stops making sense.
Integration shape
Embed the Post3 inbox or hand users into the hosted app.
A wallet can start with a Post3-hosted webview, wallet handoff links, and focused API hooks for actions or identity.
Wallet session auth uses the wallet's existing signing flow.
Brand-safe entry points keep the experience clear while Post3 hosts and operates the inbox.
Most pilots should be measured in days to weeks, not months.
Full technical detail lives on the developer page.
smallest useful integration
import { createPost3ApiClient } from "@post3/platform/api";
import type { ThreadDetail } from "@post3/platform/messaging";
const post3 = createPost3ApiClient({
baseUrl: "https://api.post3.io",
});
export async function loadWalletInbox({
chain,
address,
signMessage,
}: {
chain: "eip155:1" | "solana:mainnet";
address: string;
signMessage: (message: string) => Promise<string>;
}) {
const challenge = await post3.requestAuthChallenge({ chain, address });
const signature = await signMessage(challenge.messageToSign);
const session = await post3.verifyAuthSession({
message: challenge.messageToSign,
signature,
});
const inbox = await post3.fetchThreads(session.token, { mailbox: "active" });
const first = inbox.items[0];
const detail: ThreadDetail | null = first
? await post3.fetchThreadDetail(session.token, first.threadId)
: null;
return {
wallet: session.wallet,
inbox,
trustPanel: detail?.messages.at(-1)?.verification ?? null,
};
}Post3 Trust Panel
payment request proof
From
treasury.project.eth
Verified signer payout wallet
The signed payee wallet matches the wallet that authorized this action.
signature
SIWE verified
signer
0x9A3f...7B21
payee
0x9A3f...7B21
domain
DNS TXT passed
The wallet signed the message.
The payout wallet matches the signer.
The project identity checks passed.
Risk and continuity
If Post3 disappears, your users should not be stranded.
This is the part security, legal, and platform teams will ask about first. The answer should be direct.
Post3 is closed source today; pilot partners get direct schema, export, and verification-path review with the founder.
The data model is documented and portable, so inbox history can be exported for migration.
Post3 does not hold user funds. The risk area is delivery and verification, not custody.
The verification logic uses standard cryptography in @post3/core, so your security team can review the path independently.
No audits are claimed here. Pilot wallets get founder-level review and direct technical access.
Where Post3 is today
Built, working, founder-led, and not yet at wallet-provider scale.
The honest status is what makes this worth a pilot instead of a procurement theater.
Built solo
Post3 is built by the founder, is not VC-backed, and does not have a token.
Core product exists
Mailbox, wallet sessions, signature verification, project identity, delivery controls, exportable data, and signed actions are real product work.
Mail operations are being hardened
Public SMTP ingress is the near-term operational milestone: uptime, abuse handling, mail delivery posture, and monitoring are being tightened.
Chain support is stated precisely
Ethereum, Solana, and Bitcoin BIP-322 signature verification are implemented in @post3/core. Legacy Bitcoin Signed Message remains as a deprecated compatibility path.
Pilot stage
Post3 is looking for one to three pilot wallet integrations before approaching larger providers.
Founder support
Pilot wallets get direct implementation support instead of being handed a vendor checklist.
Not on the table
Post3 is not asking your wallet to become part of someone else's token or ad business.
The absence of these asks is the point of the wallet-provider pitch.
Post3 will not ask the wallet to issue, hold, distribute, or integrate any token.
Post3 will not ask for revenue share or take a cut of value moving through the inbox.
Post3 will not require the wallet to hand over its user list, KYC data, or behavioral data.
Post3 will not change the wallet's existing sign-in or auth flow.
Post3 will not require the wallet to surrender control of its UI to a third-party widget.
Pilot wallets
Start with one wallet, one mailbox tab, and one honest pilot.
Post3 is in early access. Wallet integrations get hands-on engineering support from the founder during pilot.