Hi @moecki , yes the proposed Approach requires all witnesses to monitor the feed and report the bridge events , Similar to how it is actually required for them to run the price feed . This approach assumes witnesses are concerned about the Bridge as much as they are concerned about the price feed .

I missed to copy whore url for the rest api server , you can get

https://reststeemvmd.steemscanner.com/steemvm/steembridge/v1/pending_withdrawals?pagination.limit=100

The Assumption and recommendation is that witnesses run their own node so the data they get is through directly querying the chain rather than relying on the third party api who can be dishonest as well .

If svm.bank starts receiving interests on SBD , Validators may propose a Governance proposal to pay SBD interests on SVM and it comes from inflation , only if the validators are able to pass the proposal . If not svm.bank will be holding surplus SBD , It wont be a problem that svm.bank has more balance than the circulating supply of steem and sbd on svm . the opposite should never happen . Both STEEM and SBD on svm can generate yeild , provided validators change inflation rate which is 0% at genesis .

Yes , We can add a minimum withdrawl , hard code and also add a additional fees on bridge events which can be burnt maybe , its just hypothesis , the current code is 1:1 and no fees or minimum is set , but its an easy addition i believe .

The birdge reuses some constants and introduces some

STEEM_BRIDGE_ORACLE_LIFETIME_BLOCKS re uses STEEM_BLOCKS_PER_DAY * 7 / 2)

3.5 days (pre-consensus deadline) .

STEEM_BRIDGE_ORACLE_MAX_CANDIDATES = 3

distinct payloads accepted per tx_hash (anti-spam)

STEEM_BRIDGE_ORACLE_MATURITY_BLOCKS (STEEM_MAX_WITNESSES + 1)

one full DPoS round (21) + 1 margin block