Mirana
Mirana partnerships - readiness checks before outreach
A Mirana partnership request is ready for outreach when it names a specific collaboration, explains why Mirana is relevant and identifies the owner, prerequisites and proof of completion. Before making contact, separate a reversible introduction from later commercial, technical or onchain commitments, then define the point where the team will pause.
Evidence to assemble before making contact
The first outreach packet should establish fit, readiness and one limited next step. It should let a recipient understand the request without inferring missing actors, permissions or dependencies.
Fit with Mirana’s investment focus
Start with the work rather than a broad sector label. Mirana has invested in Web3 companies from pre-seed through Series C. For a New Financial Infrastructure proposal, connect the requested relationship to the product, market and infrastructure involved. Labels such as crypto, Web3 or AI offer context, but they do not explain the actual fit.
One bounded outcome
Describe the smallest useful result from the first interaction. It might be a qualified introduction, a discussion about an integration or a decision on whether a liquidity conversation should proceed. State what the other party would contribute and what the requesting team already controls. A broad request for support leaves the purpose, preparation burden and stopping point unclear.
Internal authority
Name the person authorized to answer commercial and technical questions. If the request could involve tokens, contracts or regulated activity, identify the relevant legal, security and operations owners before outreach. Record any approval still pending. The contact should not discover during the first discussion that nobody can confirm the proposed scope or authorize the next step.
What makes a partnership request ready for outreach?
A request is ready when each dependency needed for the first conversation is complete or clearly disclosed. The brief should state the intended outcome, relevant product state, requested partner function and evidence expected from a successful first step. It should also distinguish a desired relationship from one already approved.
Mirana provides liquidity support to portfolio companies on a case-by-case basis. A liquidity request therefore needs its own rationale instead of appearing as an assumed benefit of contact. Define the market function being requested, the party responsible for custody and execution and the information needed for review. Leave changing commercial parameters open until the authorized parties agree them.
The commitment boundary stays explicit
An introduction permits a conversation; it does not approve a commercial agreement, technical integration or transfer of assets. Keeping those states separate preserves a reversible stopping point.
Authority for an introduction
Confirm who may send the proposal and who may speak for the requesting organization. The initial brief can explain the opportunity without promising exclusivity, announcing a relationship or displaying another organization’s marks. If a third party arranged the contact, record the scope of that introduction. Referral access does not give the intermediary authority to negotiate terms for either side.
Technical and onchain authority
A discussion involving a token, protocol or liquidity arrangement may later require network details, contract addresses, custody roles and signing permissions. Those fields belong in the review once the relevant owners are present. Outreach alone must not trigger a token transfer, contract approval or wallet signature. Confirm the counterparty identity and transaction purpose before any irreversible onchain action.
Different Mirana requests need different preparation
The requested form of support determines which evidence belongs in the brief. A distribution conversation, market connection and liquidity request depend on different owners and readiness signals.
Strategic collaboration
Mirana uses its business partnerships with Bybit and Mantle, plus its broader network, to support portfolio founders. Naming one of these organizations is not a complete request. Explain the function sought, the product state supporting it and the work each participant would need to perform. The recipient can then assess whether the proposed connection matches the available relationship and timing.
Requests involving ecosystem connections
Mirana’s ecosystem connections can involve its investment portfolio, fund partners, business partners and market makers. A request involving those connections should identify the relevant operating model. Custody, settlement, compliance and user access may differ across operating models. These market connections are strategic relationships, not blockchain bridges for moving tokens.
Selective liquidity
Liquidity preparation should describe the intended market function without inventing an allocation, rate or venue. Identify the asset role, responsible entities, custody boundary, reporting needs and conditions for stopping. Keep liquidity separate from distribution or investment discussions unless the same approved plan genuinely connects them. This separation makes later terms easier to review and reconcile.
A reversible first move
The company, requested partner function, internal owner, readiness date, completion record and follow-up window are hypothetical in this example.
A portfolio company wants an introduction to a business partner whose distribution channel may fit its product. Before contact, its owner approves a short brief describing the product state, proposed collaboration and material exclusions. The readiness signal is an internally approved request with no unresolved dependency needed for an exploratory conversation.
The commitment point is permission to share that brief and accept an introduction. No exclusivity, integration promise or asset movement follows from it. If the desired outcome changes from an exploratory meeting to a technical pilot, the inputs also change. The team must add an integration owner, security prerequisites, supported environments and approval limits before asking for the broader action.
After the introduction, the owner records whether the meeting occurred, who owns the next action and whether the request remains open. If the agreed follow-up window closes without a next step, the record becomes paused. That concrete status prevents an unanswered introduction from being reported as an active partnership.
Close the record after the first interaction
Completion evidence should match the limited action originally requested. A delivered introduction may be confirmed by an accepted connection or completed meeting. A technical discussion needs a recorded decision and owner, while a liquidity inquiry needs a clear review status. None of these records proves a broader commercial relationship unless the authorized agreement says so.
Reconcile changed assumptions before further outreach. Update the request if the product state, partner function, internal authority or desired outcome has moved. Preserve the earlier record rather than rewriting it as a success. The recorded status then tells the owner whether to schedule another discussion, revise the request or stop outreach.
Things people ask about Mirana partnerships
Can a company request a Mirana partnership before joining the portfolio?
Mirana frames its strategic collaboration and selective liquidity support around portfolio companies, so an outside company should not assume access to those channels. An initial inquiry can still explain the proposed fit and ask whether an appropriate route exists. Keep the request limited, avoid representing a relationship before approval and treat silence as an unresolved inquiry rather than consent.
Does a named Mirana business partner guarantee an introduction?
No, a named business relationship does not guarantee access, acceptance or a particular commercial outcome. State the capability the request needs and explain why the connection is relevant. The authorized parties can then decide whether an introduction fits. Do not use a partner’s logo or announce a collaboration until each organization has approved that representation.
Should confidential technical material accompany the first outreach?
Share only the material needed to assess the initial request. A non-sensitive product description, proposed collaboration and list of dependencies may be enough for the first contact. Keep private keys, seed phrases, access credentials, undisclosed contract details and sensitive customer data outside the outreach packet. More detailed material can follow under the requesting organization’s approved disclosure process.
Is a wallet signature enough to approve a partnership?
No, a valid wallet signature can demonstrate control of the signing key used for that message, but it does not establish corporate authority or contract acceptance by itself. Commercial approval should come from the authorized organization and its agreed process. Review the message, address, network and requested action before signing, especially when the signature could authorize a transaction or grant permission.
Why should liquidity terms stay separate from the initial partnership brief?
Liquidity can involve asset scope, custody, execution responsibility, incentives and reporting obligations, each requiring specific review. Folding those terms into a general outreach note can hide unresolved authority or risk. The initial brief should identify the liquidity function being considered, while authorized participants establish changing allocations, rates, venues and legal terms during the appropriate review.
Updated -