diff --git a/bip-ephemeralanchors.mediawiki b/bip-ephemeralanchors.mediawiki
new file mode 100644
index 0000000000..fd5c117b32
--- /dev/null
+++ b/bip-ephemeralanchors.mediawiki
@@ -0,0 +1,124 @@
+<pre>
+  BIP: ?
+  Layer: Application
+  Title: Ephemeral Anchors
+  Author: Gregory Sanders <gsanders87@gmail.com>
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
+  Status: Draft
+  Type: Informational
+  Created: 2023-01-11
+  License: CC0 1.0 Universal
+</pre>
+
+==Introduction==
+
+===Abstract===
+
+Ephemeral Anchors are a mempool policy carve-out that allows any value utxos,
+even 0-value dust, to be created, provided it is also spent within the same
+mempool package.
+
+===Motivation===
+
+Relay dust limits have been in place in most implementations of the Bitcoin
+protocol to discourage the creation of UTXOs that are never spent in the future,
+bloating the UTXO set and increasing the validation burden for validating
+nodes.
+
+With [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transactions
+and basic package relay, users can generate and propogate 0-fee transactions provided
+a descendant transaction includes the proper fee for the package. In many cases
+these fees can be directly sourced from a freely spendable output, with the resulting
+change output being decremented by the required fee amount.
+
+In some cases however there are no freely spendable outputs to source this fee value
+from, and in these cases an "anchor" is employed.
+
+[https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local_anchor-and-to_remote_anchor-output-option_anchors LN]
+allows a small amount of contract value to be given to an output to merely allow network relay
+by avoiding dust checks, but not as the primary source of fee funds. Instead the child transaction
+spending the anchor is given the responsibility of bringing funds.
+
+It is cleaner for this abstraction and others if instead of requiring
+dust values in anchors, the anchor itself can be 0 value.
+
+===Typical Configurations===
+
+For anchors using TRUC transactions, it's expected that they would take two output script forms:
+
+1. Keyed anchor: A key, shared by possibly multiple privileged parties, is used to encumber the anchor. This could also be `tr()`, `p2wsh()` or any
+output type that allows key material.
+1. Un-keyed anchor: `P2SH(OP_TRUE)` or `P2WSH(OP_TRUE)`, depending on the the user's need for lack of txid malleability. Further policy
+extensions could allow output templates such as the output script <code>OP_1 <0x4e73></code> or a bare `OP_TRUE`.
+
+===Example Use Cases===
+
+* Batched payments with segregated fee pools: Batched payments that can be fee bumped without access to customer deposit-related key material
+* Simplified watchtowers/accelerators: No requirement for watchtowers to be registered with privileged key material, and no value to steal by those watchtowers
+* Multiparty smart contracts: LN BOLTs can be revamped to remove value-sapping anchors.
+* LN-Symmetry: During the contest period, no anchor value can be sourced endogenously.
+* [https://bitcoin.stackexchange.com/questions/100537/what-is-spacechain Spacechains]
+* Ark transactions
+* Timeout Trees
+
+===Related Work===
+
+[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021334.html SIGHASH_GROUP] style proposals are an alternative method of bringing funds to a transaction without involving CPFP by enacting a softfork. Making these pin-resistant may require follow-on policy work, or [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html more general covenants] to directly stop pins we want to avoid. The drawbacks of these are the necessity of a softfork.
+
+[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html Transaction Sponsors] is a softfork proposal to allow transactions to
+indirectly sponsor transactions with no explicit relationship in the classical utxo
+model. Ephemeral Anchors can be viewed as a type of opt-in transaction sponsors implemented
+purely in policy.
+
+Using a 0-value CPFP anchor is not a new idea, see:
+
+* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015931.html LN-dev discussion on 0-value anchors]
+
+The discussion lacked a solution to the issue of the dust entering into the utxo set
+causing negative externalities.
+
+==Definitions==
+
+Ephemeral anchor: An output with dust value which is immediately spent by a child transaction.
+
+Ephemeral anchor transaction: A transaction that has an ephemeral anchor
+
+==Specification==
+
+When received by a peer for inclusion to the mempool an ephemeral anchor transaction MUST:
+
+* Be an otherwise valid [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transaction which enforces topology constraints
+* Be 0-fee
+* Have only one dust value output
+* Have the dust value spent in the same TRUC cluster
+
+or will be rejected by policy. All other policy checks are left in place.
+If included in an otherwise valid block, these additional constraints do not apply
+as this is a policy-only change.
+
+== Backward compatibility ==
+
+Ephemeral anchor spends were previously non-standard, so there are no known conflicts
+with previous usage.
+
+==Implementation==
+
+https://github.com/bitcoin/bitcoin/pull/30239
+
+==Acknowledgements==
+
+Thank you to all those listed for foundational work
+and insightful feedback(in last name order):
+
+* Richard Myers
+* James O'Beirne
+* Antoine Poinsot
+* Antoine Riard 
+* Jeremy Rubin
+* Bastien Teinturier
+* Anthony Towns
+* Gloria Zhao
+
+==Copyright==
+
+This document is licensed as Creative Commons CC0 1.0 Universal.